Warum benutzen alle React, aber wir müssen es nicht benutzen? - Die Geschichte des Frontend-Krieges und die Gründe für die Entstehung von Hotwire
Wenn man heutzutage über Webentwicklung spricht, hört man immer dieselben Worte.
"Das Frontend sollte mit React gemacht werden."
"Jetzt benutzt jeder React."
"Wenn du React nicht lernst, wirst du kein Entwickler."
Aber ist das wirklich so?
Nein, um genau zu sein, ist es nur zur Hälfte richtig.
Es ist wahr, dass React eine gute Bibliothek ist.
Aber das Problem ist...
Die "notwendigen Situationen" für React machen nur etwa 10-20% des gesamten Webdienstes aus.
Und erstaunlicherweise gehören die meisten Dienste, die von Rails-Entwicklern erstellt werden, nicht zu diesen 10-20%.
1. Bis React seinen Platz gefunden hat, sind viele Bibliotheken heldenhaft gefallen
Es gibt eine Tatsache, die Anfängerentwickler oft nicht kennen.
React war nicht von Anfang an der "unangefochtene Champion".
Die vielen Frameworks und Bibliotheken davor sind fast vollständig verschwunden.
- AngularJS (gestorben)
- Ember.js (kurz vor dem Tod)
- Backbone.js (fast verschwunden)
- Knockout.js
- ExtJS
- Meteor Frontend-Layer
- jQuery + SPA-Frameworks
- Mithril, Riot, Preact...
Das Frontend-Ökosystem war ein "Kampf der 100 Technologien in 10 Jahren, von denen 98% verschwanden".
Der Grund, warum nur React überlebt hat, ist groß:
- Die Struktur war halbwegs gut
- Die Wartung war halbwegs einfach
- Die Unternehmen haben es angenommen
Aber das bedeutet auch, dass React irgendwann verschwinden wird, weil die Essenz der Frontend-Technologie immer gleich bleibt.
2. React wird immer größer und komplexer (Realität)
Am Anfang war React wirklich einfach.
"Die Benutzeroberfläche ist eine Funktion des Zustands."
Aber wie ist React heute?
- React
- ReactDOM
- JSX
- Babel
- Webpack
- Vite
- Next.js
- Zustand
- Redux
- Suspense
- Server-Komponenten
- Hydratisierung
- Client-/Server-Grenze
- Streaming
- Routing
- Bündler
- Compiler-basiertes Rendern...
All diese Dinge sind zu "unverzichtbaren Diskussionen" innerhalb des React-Ökosystems geworden.
React ist nicht mehr nur eine einfache Bibliothek.
React ist zu einer komplexen Welt geworden, die jedes Jahr schwieriger wird.
Was passiert dann?
- Der Einstieg für neue Entwickler wird schwieriger
- Wenn das gesamte Team keine React-Experten sind, steigt die Wartungsschwierigkeit
- Die Anfangsgeschwindigkeit des Projekts wird drastisch langsamer
- Der Server ist einfach, aber das Frontend wird zur Hauptursache der Komplexität
Und diese Frage stellt sich:
"Braucht mein Service wirklich React?"
3. Die meisten SaaS- und Webdienste benötigen kein React
Die Situationen, in denen React benötigt wird, sind hauptsächlich zwei:
Komplexe SPAs, bei denen sich die Benutzeroberfläche kontinuierlich ändert
(z.B. Figma, Slack (Web), Notion, Trello usw.)Sehr große Frontend-Organisationen und Mega-Projekte, die eine Zusammenarbeit mehrerer Teams erfordern
Aber wie sieht es mit den Diensten aus, die von Rails-Entwicklern erstellt werden?
- CRUD-Dienste
- Dashboards
- Blogs
- Gemeinschaften
- Datenorientierte Dienste
- Form-zentrierte Dienste
- Kundenverwaltung
- Interne Tools
- SaaS
- E-Commerce-Backoffice
Für solche Dienste ist nicht einmal die Hälfte der Funktionen von React erforderlich.
Und wenn man React verwendet, wird die Entwicklungsgeschwindigkeit langsamer und die Komplexität nimmt stark zu.
4. Hotwire ist die Technologie, die vor diesem Hintergrund entstanden ist
Hotwire ist der von Rails vorgeschlagene Technologiestack und basiert auf dieser Philosophie.
"80% des Frontends müssen nicht so komplex sein wie React."
Die Struktur von Hotwire ist einfach:
- Turbo (HTML-Streaming + partielle Updates)
- Stimulus (kleiner JavaScript-Engine)
- Kabel + Streams (Echtzeit)
Aber das Wichtigste ist dies.
Die Art und Weise, wie HTML selbst aktualisiert wird, ist in den meisten Webdiensten am schnellsten, einfachsten und am einfachsten zu warten.
Im Gegensatz zu React gibt es keinen komplizierten Prozess wie Zustandsänderung → Diff → Rendern → Hydratisierung...
Hotwire folgt genau der Philosophie von Rails:
- Einfachheit
- Produktivität
- Iterationsgeschwindigkeit
- Wartbarkeit
- Weniger Code
- Entwicklerglück
Und die erstaunliche Realität:
Tatsächlich ist Hotwire dreimal schneller als React, die Codebasis ist ein Fünftel so groß und die Fehler werden dramatisch reduziert.
5. Warum man kein React verwenden muss - Hotwire hat das bereits gelöst
Von den 10 Problemen, die React lösen wollte, löst Hotwire 7-8 Probleme auf serverzentrierte Weise.
Zum Beispiel:
| Problem | React-Methode | Hotwire-Methode |
|---|---|---|
| UI-Update | Diff-Berechnung → Rendern | Der Server sendet einfach HTML-Schnipsel |
| Zustandsverwaltung | Redux/Zustand | Serverzustand = UI-Zustand |
| Routing | Frontend-Router | Optimierung der Seitennavigation mit Turbo |
| Echtzeit | WebSocket + Client-Rendern | Sofortiges HTML-Update mit Turbo Stream |
| SEO | Separate Einstellungen | 100% Server-Rendering |
| Build | Babel/Webpack/Vite | Keine (Kein Build!) |
| Komplexität | Hoch | Niedrig |
Hotwire steigert die Produktivität von Rails-Entwicklern dramatisch.
6. Wie wird es mit React weitergehen? Es wird irgendwann untergehen. Ziemlich sicher.
Denn die Geschichte des Frontends wiederholt sich immer wieder.
- Anfangs war es eine einfache UI-Bibliothek → Immer funktionsreicher → Komplexer → Organisation kann nicht mithalten → Andere Technologien tauchen auf → Generationswechsel
Auch React geht diesen Weg.
Tatsächlich gibt es bereits Anzeichen dafür.
- React Server Components sind zu komplex, Entwickler rebellieren
- Leistungsprobleme
- Next.js dominiert die React-Regeln (React ist nicht mehr unabhängig)
- Konkurrenten (Solid, Qwik, Svelte, HTMX usw.) tauchen auf
- "No Build + serverzentriertes Web" wird wieder populär
Aktuell sagen Entwickler eher:
"Das Web ist heutzutage viel zu kompliziert. Wir brauchen wieder Einfachheit."
Dieser Trend hat sich historisch immer bewahrheitet.
- Mainframe → PC (Rückkehr zur Einfachheit)
- SOAP → REST (Rückkehr zur Einfachheit)
- Ära von jQuery → React (Rückkehr zur Einfachheit)
- Komplexe SPAs → Hotwire/HTMX (Rückkehr zur Einfachheit)
React wird letztendlich verschwinden. Es ist nur eine Frage des "Wann".
Fazit - Wir wählen nicht die Technologie, sondern die Richtung
Es geht nicht darum, nicht React zu lernen.
Wenn React benötigt wird, sollte es unbedingt verwendet werden.
Aber die meisten Dienste benötigen kein React. Sobald komplexe Technologien verwendet werden, verlangsamt sich die Geschwindigkeit und die Wartung wird schwieriger.
Rails + Hotwire sagen Folgendes:
"Das Web sollte von Natur aus einfach sein.
Der Server gibt HTML aus, der Browser zeigt es an.
Alle Komplexität sollte nur bei Bedarf schrittweise hinzugefügt werden."
Diese Philosophie passt perfekt zur Art der Entwicklung im KI-Zeitalter.
Besonders für Anfänger ist Hotwire eine starke Alternative.
- Schnell
- Einfach
- Klar
- Weniger Fehler
- Serverzustand = UI-Zustand
- Kein Build-System
- Einfache Wartung
- Optimal für Einzelentwickler
Und das Wichtigste:
Hotwire ist eine Technologie, die viel länger halten wird als React. Die Philosophie von Rails hat 20 Jahre überdauert und wird sich auch in Zukunft nicht ändern.