React Entwicklung — und die Frage, ob ihr React überhaupt braucht

8+ Jahren im Einsatz

Frontend und Backend aus einer Hand

Next.js und React

Womit wir im Frontend arbeiten

Dashboards

Auswertungen mit Live-Daten, Filtern und Diagrammen — der Fall, für den React tatsächlich gemacht ist.

Kundenportale

Self-Service-Oberflächen mit Rollen und Rechten, angebunden an ERP oder Warenwirtschaft.

KI-Oberflächen

Chat- und Assistenzoberflächen mit Streaming-Antworten, Markdown-Darstellung und Fehlerzuständen.

Editoren & Formulare

Mehrstufige Eingaben mit Zwischenspeichern, Validierung und Abhängigkeiten zwischen Feldern.

Interne Werkzeuge

Fachanwendungen für Teams, die täglich damit arbeiten — dort zahlt sich gute Bedienbarkeit direkt aus.

Übernahme & Modernisierung

Bestehende React-Projekte auf aktuelle Versionen bringen, Abhängigkeiten aufräumen, Tests nachziehen.

Wann braucht ein Projekt React — und wann nicht?

React lohnt sich bei komplexem Zustand im Browser: Editoren, Dashboards mit Live-Daten, mehrstufige Formulare, app-artige Oberflächen. Bei überwiegend darstellenden Seiten mit ein paar interaktiven Stellen ist serverseitiges Rendern mit HTMX oder Django-Templates deutlich günstiger — es spart ein komplettes Frontend-Projekt samt Build-Kette. Wir raten in etwa der Hälfte der Anfragen von React ab.

Wie wird ein React-Frontend an ein Django-Backend angebunden?

Über eine REST- oder GraphQL-API, meist mit Django REST Framework oder Django Ninja. Die Entscheidungen, die dabei zählen, betreffen nicht React: Wie werden Sitzungen und Berechtigungen gehandhabt, wie sieht die Fehlerbehandlung aus, wer besitzt das Datenschema. Wir bauen beide Seiten, was diese Abstimmung deutlich verkürzt.

React oder Next.js?

Next.js, wenn die Oberfläche öffentlich und auffindbar sein soll — serverseitiges Rendern ist für Suchmaschinen und für die erste Ladezeit klar im Vorteil. Reines React reicht für interne Anwendungen hinter einer Anmeldung, wo Auffindbarkeit keine Rolle spielt und der Zusatzaufwand von Next.js keinen Gegenwert hat.

Was kostet ein React-Frontend?

Eine überschaubare Oberfläche mit fünf bis zehn Ansichten, angebunden an eine bestehende API, liegt bei 15.000 bis 35.000 Euro. Ein Dashboard mit Live-Daten, Rollen und komplexen Tabellen eher bei 40.000 bis 80.000 Euro. Der größte Kostentreiber ist selten React, sondern wie klar die Ansichten vorher beschrieben sind.

Übernehmt ihr bestehende React-Projekte?

Ja. Wir beginnen mit einem Assessment: React-Version, Zustandsverwaltung, Testabdeckung, Build-Kette und Abhängigkeiten. Gerade bei Frontend-Projekten ist der Abhängigkeitsstand oft das drängendste Problem — Pakete, die seit Jahren nicht gepflegt werden, blockieren jedes Versions-Update.

Macht ihr auch Design?

Wir setzen bestehende Entwürfe um und gestalten Oberflächen, bei denen Funktion vor Wirkung steht — Fachanwendungen, Dashboards, interne Werkzeuge. Für Markenauftritte und gestalterisch anspruchsvolle Websites arbeitet ihr besser mit einer Designagentur; wir übernehmen dann die Umsetzung.

Warum wir bei der Hälfte der Anfragen von React abraten

React hat sich als Standardantwort etabliert, auch für Projekte, die davon nichts haben. Der Preis ist real: ein zweites Deployment, eine Build-Kette, eine Abhängigkeitslandschaft mit eigenem Pflegebedarf und die Notwendigkeit, Daten zwischen Server und Browser zu synchronisieren, die vorher einfach im Template standen.

Für eine Fachanwendung mit Formularen, Listen und Detailansichten leisten Django-Templates mit HTMX praktisch dasselbe, bei einem Bruchteil des Aufwands. Der Unterschied wird erst spürbar, wenn der Zustand im Browser komplex wird — mehrere voneinander abhängige Bereiche, Live-Aktualisierungen, Offline-Fähigkeit. Dann ist React die richtige Wahl und die Alternativen werden unangenehm.

Unsere Empfehlung hängt deshalb nicht am Geschmack, sondern an einer Frage: Gibt es Zustand, der nur im Browser existiert und nicht sinnvoll auf den Server gehört? Wenn ja, React. Wenn nein, spart euch das Projekt.

React an Django anbinden

Die technische Anbindung ist der einfache Teil: Django REST Framework oder Django Ninja liefern die API, React holt sich die Daten. Interessant sind die Entscheidungen daneben, und die betreffen nicht React.

Wie werden Sitzungen gehandhabt — Cookie-basiert oder mit Token, und was passiert beim Ablauf? Wo liegt die Berechtigungsprüfung, und ist sie über die API umgehbar? Wer besitzt das Datenschema, und wie werden Änderungen daran koordiniert, ohne dass eine Seite bricht? Wie sehen Fehlerzustände aus, wenn die API langsam ist oder nicht antwortet?

Diese Fragen kosten in getrennten Teams regelmäßig Wochen an Abstimmung. Wenn dieselben Leute beide Seiten bauen, werden sie in einem Gespräch entschieden — das ist der eigentliche Grund, warum wir Frontend und Backend zusammen anbieten.