React vs. Backbone im Jahr 2025

• Ein Vergleich zwischen Backbone aus den frühen 2010er-Jahren und React im Jahr 2025, der hinterfragt, wie groß der tatsächliche Fortschritt im Frontend in 15 Jahren wirklich war
• React wirkt auf den ersten Blick schlank und modern, verbirgt seine Einfachheit intern jedoch hinter komplexen Abstraktionsschichten
• Backbone ist zwar wortreicher im Code, aber Ereignisfluss und DOM-Manipulation sind explizit, sodass auch Einsteiger das Verhalten leicht nachverfolgen können
• Bei React ist Debugging wegen Themen wie State-Management, Dependency-Arrays und Closure-Problemen schwierig, wenn man das Innenleben nicht versteht
• Letztlich wird das Wesen „Ereignisse + Zustand = UI“ wieder in Erinnerung gerufen und der Bedarf an einem neuen Modell mit Einfachheit und einer hackbaren Struktur aufgeworfen

---

15 Jahre Fortschritt

• Ein Beispiel für ein Passwort-Eingabefeld, einmal geschrieben mit einem Framework der 2010er (Backbone) und einmal mit React, das sich über mehr als zehn Jahre entwickelt hat
  • Beide Implementierungen sind ähnlich lang und funktional identisch
  • React wurde durch unzählige Entwicklerstunden und ein riesiges Ökosystem unterstützt
  • Der Autor merkt jedoch an, dass weniger interessant sei, „wie viel besser React geworden ist“, sondern eher, „wie wenig Fortschritt es gegeben hat“
• React liefert die Illusion äußerer Einfachheit, tatsächlich steigt die Verständnishürde aber durch komplexe Abstraktionen
  • Backbone stellt den einfachen Ablauf explizit dar: Ereignis tritt auf → Handler läuft → HTML wird erzeugt → DOM wird eingefügt
  • React dagegen verbirgt die internen Abläufe, und sobald man über einfache Beispiele hinausgeht, entstehen Probleme, die sich nur mit Verständnis der internen Mechanismen lösen lassen

Die Illusion der Einfachheit (The Illusion of Simplicity)

• React-Code sieht sauber aus, aber das ist das Ergebnis einer Entscheidung für abstrakte Komplexität statt expliziter Einfachheit
  • Backbone ist wortreich, zeigt aber klar, „was wann passiert“
  • Auch Einsteiger können den Codefluss leicht verfolgen
• In React sind interner Zustand und Rendering-Logik verborgen, wodurch unerwartete Bugs häufig auftreten
  • Beispiel: Wenn bei Listeneinträgen der key auf den Index geändert wird, erkennt React sie als andere Komponenten und setzt den Zustand zurück
  • Wenn value zu undefined wird, kommt es durch den Wechsel von unkontrollierter zu kontrollierter Komponente zum Zurücksetzen des Eingabewerts
• Auch Endlosschleifen bei der Verwendung von useEffect sind ein häufiges Problem
  • Wenn das Dependency-Array Objekte enthält, die bei jedem Rendern neu erzeugt werden, wertet React das als Änderung
  • Um das zu verhindern, braucht man mit useMemo und useCallback eine Stabilisierung von Identitäten
  • Dadurch muss man auf Konzepte achten, die früher keine Rolle spielten
• Es gibt auch das Problem, dass Click-Handler auf veralteten Zustand (stale state) zugreifen
  • Der Grund ist, dass Funktionen den Zustand zum Zeitpunkt ihrer Erzeugung capturen
  • Lösungen sind, den Zustand ins Dependency-Array aufzunehmen oder funktionale Updates wie setState(x => x + 1) zu verwenden
  • Beide Methoden wirken jedoch eher wie ein Workaround

Magie hat einen hohen Preis (Magic Has a High Price)

• Diese Probleme sind keine Ausnahmefälle, sondern allgemeine Probleme, die in Apps ab mittlerer Größe häufig auftreten
  • Für Debugging muss man den Reconciliation-Algorithmus, die Render-Phase und den Scheduler (Batch Update) verstehen
  • React ist so aufgebaut, dass es „funktioniert, auch wenn man nicht weiß warum“, aber sobald Probleme auftreten, muss man das Innenleben kennen, um sie zu lösen
• Die Komplexität ist so groß, dass es sogar heißt, man müsse React selbst einmal bauen, um es wirklich zu verstehen
  • Es gibt Tutorials wie “Build your own React”
  • Dass man für einen simplen Passwort-Validator Virtual DOM, Scheduling-Prioritäten und Concurrent Rendering verstehen soll, hat jedoch eine kritische Aussagekraft
• Backbone und jQuery besitzen eine ehrliche und hackbare Struktur
  • Man kann den Quellcode direkt ansehen und verändern
  • Auf DOM-Methoden basierend sind sie leicht zu verstehen und zu erweitern
  • Dagegen erschweren die Abstraktionsschichten von React den Zugriff auf und die Veränderung des Inneren

Was kommt als Nächstes? (So, What's Next?)

• Letztlich versuchen sowohl React als auch Backbone, dasselbe Problem zu lösen: „Ereignisse + Zustand = UI“
• In großen Apps mag die Komplexität von React gerechtfertigt sein, für die meisten kleinen und mittleren Apps ist sie jedoch eine übermäßige Last
• Es braucht ein neues UI-Modell mit Einfachheit und Transparenz
  • Ein System, das so robust wie das DOM, aber intuitiv ist
  • Mit einer sofort verständlichen und veränderbaren Struktur wie bei Backbone oder jQuery

[shakespeares]

Bei kleinen bis mittelgroßen Apps scheint es besser, JavaScript-Klassen zu entwerfen, statt auf Backbone oder jQuery zu setzen, um sich auf das Nächste vorzubereiten.
Die Templates in jQuery oder Backbone wieder auswendig zu lernen und damit weiterzumachen, wirkt wie ein Rückschritt.

[GN⁺]

Hacker-News-Kommentare

• Ich habe alles verwendet: Backbone, Angular 1, Ember und React
  Man darf nicht übersehen, warum React populär geworden ist. Bei Komposition von Komponenten, Ereignisbehandlung, State-Management und effizienten DOM-Updates hat React chronische Probleme bestehender Frameworks gelöst
  Bei Backbone war das Management des DOM-Lebenszyklus komplex, und Event-Handler mussten als Strings angegeben werden, was die Wartung erschwerte. React hat diese Probleme mit unidirektionalem State-Flow und virtuellem DOM vereinfacht
  Wenn ich heute pures JS verwenden wollte, hielte ich eine Template-Lösung wie lit-html für deutlich besser als Backbone

  • Das Beispiel wirkt nicht realistisch. Wenn man vergleichen will, ist TodoMVC repräsentativ. Wenn man sich diesen Code der Backbone-Version ansieht, ist das ein Wartungsalbtraum. Die React-Version (Link) ist viel klarer
    Frontend war früher schon komplex und ist es heute auch, aber heute ist es deutlich weniger schmerzhaft
  • Stimme zu. React ist auch nicht perfekt, aber am Ende ist es eine Frage des Kompromisses. Ganz gleich, welches Tool man nutzt: Entwickler müssen diese Komplexität tragen. Wichtig ist, ob wir den richtigen Kompromisspunkt wählen
  • Heutzutage gibt es neben React viele Frameworks, die solche Funktionen bieten. Das ist kein exklusives Privileg von React

• Die Komplexität einer App entsteht nicht durch die Anzahl der Komponenten, sondern durch State-Management
  Wegen des bidirektionalen Datenflusses im Backbone Store hatte ich oft Probleme mit eingefrorenen UIs. Die Innovation von React war die Flux-Architektur rund um unidirektionalen Datenfluss
  Ein gutes Framework ist für mich ein Werkzeug, das einen natürlich in den „Pit of Success“ führt. React hat diese Rolle gut erfüllt

  • Frontend-Entwicklung vor React/Flux/Redux war wirklich Chaos. Selbst bei Code mit weniger als 1000 Zeilen gab es State-Management-Probleme
  • Ich bin der Autor. Unidirektionaler Datenfluss hat Probleme tatsächlich gelöst, aber React hat auch neue Komplexität mitgebracht
    Probleme wie stale closures, endlose useEffect-Schleifen oder zurückgesetzte Eingaben durch geänderte Keys gab es in Backbone nicht
    Die Probleme von Backbone waren sichtbar und leicht zu debuggen, aber die Probleme von React verstecken sich hinter Abstraktionen
    Die meisten Apps haben nicht die Größenordnung von Facebook, daher kann ein expliziter und einfacher Ansatz sogar besser sein
  • Ich habe lange Angular gemacht und bin dann zu React zurückgekehrt. Es ist nicht perfekt, aber React bringt Entwickler dazu, in die richtige Richtung zu coden
  • Komponenten selbst sind wieder eine zusätzliche Komplexität. Markup, Events, Business-Logik und Accessibility werden zu einer riesigen Struktur zusammengebunden. Am Ende ist das nur Komplexität für Bequemlichkeit; Einfachheit gibt es nicht umsonst
  • Ist „unidirektionaler Datenfluss“ nicht eigentlich ziemlich ähnlich zum Grundverhalten des DOM? Was das React-Team gebaut hat, war Flux, nicht Flow

• Beliebte Technologien pauschal als „schlecht“ abzutun, wirkt wie eine Art naive Arroganz
  Natürlich garantiert Popularität keine Qualität, aber anzunehmen, dass brillante Ingenieure weltweit sich alle haben täuschen lassen, ist überzogen

  • Beliebte Technologie hat nicht immer recht. Man muss nur an die Hypes um MongoDB, Kafka und Microservices denken
    Wenn Großunternehmen und Marketing etwas pushen, übernehmen CTOs es, und wenn die eigene Karriere daran hängt, sagt niemand „das ist nicht so toll“. Popularität ≠ Eignung
  • Ich bin der Autor. Die Analogie mit den „Paläo-Influencern“ ist interessant, aber neu heißt nicht automatisch gut
    React hat nicht allein durch technische Überlegenheit gewonnen, sondern auch dank Facebooks Marketing und der sich selbst verstärkenden Dynamik des Ökosystems
    Selbst nach 15 Jahren sind Code-Länge und Komplexität nicht drastisch gesunken. Es ist nur auf andere Weise komplexer geworden
    Der Blick zurück ist keine Nostalgie, sondern soll prüfen, ob wir unverhältnismäßige Komplexität hinzugefügt haben
  • Bei React oder Tailwind ist ein Vorteil ihre Hiring-Freundlichkeit. Der Grund ist eher leichtes Onboarding als technische Perfektion
    Das Web wirkt immer noch wie der Wilde Westen der Design Patterns. Als ich das akzeptiert habe, war ich innerlich ruhiger
  • React als „dumm“ abzutun, wirkt wie eine Mischung aus Arroganz und Unwissenheit. Es gibt Gründe, warum Millionen Entwickler es nutzen. Eine vollständige Ablehnung ignoriert Chesterton’s Fence
  • Eher als Arroganz könnte es auch Erfahrung aus einer anderen Perspektive sein. Manche mögen das React-Ökosystem, andere mögen es nicht, weil es so viel JS mit sich bringt
    Letztlich muss man je nach Projekt die Trade-offs neu bewerten

• Die Behauptung „für einfache Dinge braucht man React nicht“ ist ein verbreiteter React-Irrtum (React fallacy)
  React an simplen Beispielen zu bewerten, ist wie „eine Sprache anhand der Länge von Hello World zu beurteilen“
  Der Grund, React auch für einfache Dinge zu verwenden, ist, dass man es auch für komplexe Dinge verwendet. Ein konsistentes Toolset ist bei der Wartung von Vorteil

  • „Wir nutzen es für komplexe Dinge, also auch für einfache“ ist ein bisschen so, als würde man mit dem Lkw zum Einkaufen fahren. Am Ende ist die Wahl des geeigneten Werkzeugs entscheidend

• Backbone sah „wie ein Framework aus, war in Wirklichkeit aber ein Haufen Glue Code“
  Der eigentliche Sieg von React war, dass direkte DOM-Manipulation nicht mehr nötig war und reaktives State-Management möglich wurde. Diese beiden Dinge haben die Produktivität stark erhöht

  • Als jemand, der früher viele Backbone-Tutorials geschrieben hat, empfinde ich ein wenig Nostalgie
    Alter Tutorial-Link, Archiv-Version
    Heute interessiert mich stärker, wie LLMs Code verstehen. Deklarative Syntax wie JSX ist LLM-freundlich
    Aber React nach useEffect wirkt in Bezug auf Ausdruckskraft und Explizitheit eher verschwommener
  • Marionette hat viel vom Boilerplate in Backbone reduziert
  • Es wird die Frage gestellt, ob React ein eingebautes State-Management hat

• Es wird gut sichtbar, warum React so populär geworden ist
  React-Code besteht größtenteils aus purem JS und HTML, und im Kern braucht man nur useState. Es ist intuitiv und auch ohne Dokumentation verständlich
  Backbone hing bei der Wartbarkeit an String-Selektoren wie .space-y-2. Wenn man nur einen Klassennamen änderte, ging die halbe App kaputt
  React hat dieses Problem strukturell gelöst

  • Der Witz kommt auf, „der Artikel sei wohl nicht selbst geschrieben, sondern von Claude schreiben lassen“

• Bei Backbone-Code ist klar, „was wann passiert“, während man bei React die internen Abläufe verstehen muss
  Ich selbst habe Dan Abramovs Guide zu useEffect und Mark Eriksons Blog mehrfach gelesen, um zu verstehen, wann React was tut
  Backbone-Code habe ich auch nach 10 Jahren sofort verstanden

• Vor 6 Jahren haben wir ein Team von Backbone auf Angular umgestellt
  Backbone war intuitiv und ohne Magie, also gut für Junioren, aber am Ende waren TypeScript und Angular systematischer
  Jetzt nutzen wir NG20 und sind zufrieden. Wenn Browser irgendwann mehr Funktionen nativ bereitstellen, kehren wir vielleicht wieder zu einem einfacheren Ansatz zurück

• Wir programmieren immer auf Abstraktionen
  Entscheidend ist, ob diese Abstraktionen Produktivitätsgewinn im Verhältnis zur Komplexität bringen und ob man ihnen vertrauen kann
  Selbst im schlimmsten Fall müssen sie noch debuggbar sein

• React verarbeitet Undo-Verhalten in Eingabefeldern natürlicher als Backbone
  Backbone macht Undo zeichenweise, React rückgängig pro Wort

  • Ich verstehe nicht, warum es besser sein soll, das Standardverhalten des Browsers zu überschreiben. Das erinnert eher an JS-Bibliotheken, die natürliches Scrollen kaputtmachen
  • Interessanterweise verhält sich das in Chrome anders, aber in Firefox funktionieren beide Frameworks gleich
  • Ich finde die Backbone-Variante besser
  • Welches Verhalten die „richtige Antwort“ ist, ist am Ende eine Frage des persönlichen Geschmacks