Es gibt Meinungen in der Softwareentwicklung, die polarisieren – und das hier ist definitiv eine davon: Ich halte React für überbewertet. Genauer gesagt, React erinnert mich zunehmend an jQuery in seinen letzten Jahren. Einst revolutionär, mittlerweile oft mehr Hindernis als Hilfe.
Diese Meinung kommt nicht aus dem Elfenbeinturm. Ich habe selbst über sechs Jahre lang Anwendungen mit React entwickelt – vom kleinen internen Tool bis zur ausgewachsenen SaaS-Plattform. Ich kenne das Ökosystem in- und auswendig, von Hooks über Context bis zu Routing und Performance-Optimierung. Aber genau aus dieser Erfahrung heraus habe ich begonnen, nach Alternativen zu suchen. Heute entwickle ich Anwendungen mit HTMX, Web Components (Lit), Tailwind CSS und TypeScript – ganz ohne React. Und das nicht aus Trotz, sondern weil es einfacher, leichter und oft schlicht besser funktioniert.
Das Problem mit React: Wenn alles wie ein Nagel aussieht
React ist in vielen Teams zur Standardlösung geworden – unabhängig davon, ob es wirklich die beste Option für das jeweilige Projekt ist. Das erinnert stark an jQuery in den 2010ern: Es war überall, selbst dann, wenn einfache DOM-Manipulationen oder Vanilla JS völlig ausgereicht hätten. Bei React ist es heute ähnlich: Selbst für Landingpages oder einfache Formulare wird gleich das ganze Framework geladen.
Ein häufig genutztes Argument ist, dass man für komplexe UIs eine leistungsfähige Bibliothek wie React eben „brauche“. Aber genau diese Komplexität ist in vielen Fällen hausgemacht. Wer HTMX einmal ausprobiert hat, weiß, wie weit man mit reinem HTML, ein paar Attributen und einem serverseitigen Backend kommt:
<!-- HTMX: Einfacher Like-Button mit Live-Update -->
<button hx-post="/like" hx-swap="outerHTML">
👍 Like
</button>
Kein State-Management, kein useEffect, kein Context. Einfach HTML, das funktioniert. Und wenn mehr Dynamik nötig ist, ergänze ich gezielt mit Web Components in Lit:
// Lit: Komponente für eine Bewertung
@customElement('star-rating')
export class StarRating extends LitElement {
@property({ type: Number }) value = 0;
render() {
return html`
${[1, 2, 3, 4, 5].map(
i => html`
<span @click=${() => this.value = i}>
${i <= this.value ? '★' : '☆'}
</span>
`)}
`;
}
}
Der Vorteil: Ich muss mich nicht um einen komplexen Render-Loop kümmern oder mit Re-Renders kämpfen. Alles bleibt übersichtlich und modular.
Web Components in der Praxis: So einfach ist Lit im HTML
Ein häufiges Missverständnis ist, dass Web Components schwer zu integrieren seien. Das Gegenteil ist der Fall: Sobald eine Komponente registriert ist, kannst du sie ganz normal im HTML verwenden – als wäre sie ein Standard-Element.
Nehmen wir die star-rating-Komponente aus dem vorherigen Beispiel. Sie könnte in einer Produktseite oder einem Bewertungsformular einfach so eingebunden werden:
<!-- Beispielhafte Verwendung einer Web Component -->
<article>
<h2>Bewerte dieses Produkt</h2>
<star-rating value="3"></star-rating>
</article>Das war's.
Kein Mounting, kein spezielles Attributsystem, kein zusätzlicher JavaScript-Wrapper. Lit kümmert sich im Hintergrund um die Aktualisierung des DOMs und reagiert automatisch auf Änderungen an Properties. So entsteht eine klare Trennung: HTML beschreibt die Struktur, Lit implementiert die feingranulare UI-Logik – und alles funktioniert zusammen, ohne dass man einen riesigen Build-Stack braucht.
Web Components sind damit frameworkunabhängig, wiederverwendbar und nativ browserkompatibel – im Gegensatz zu React-Komponenten, die immer an React und seinen Render-Loop gebunden bleiben.
React skaliert – aber auch in die falsche Richtung
React bringt viel mit: Routing, Zustand, Styling, Testing – das meiste davon kommt aber nicht aus dem Core, sondern aus Drittbibliotheken. Wer einmal versucht hat, ein neues Projekt „von Hand“ aufzusetzen, weiß, wie schnell das in Boilerplate und Entscheidungschaos endet. Oder man nutzt gleich ein Meta-Framework wie Next.js, das vieles vorgibt – und damit auch wieder einschränkt.
Noch schlimmer wird's wenn man ein API zwischen Front- und Backend einziehen muss, z.B. mit Apollo GraphQL. Dann mischen sich im React Code ganz schrecklich das UI und die Abfragen. Igitt!
In meinen aktuellen Projekten ist die Architektur um ein Vielfaches schlanker. HTMX liefert Server-Interaktivität, Lit übernimmt modulare UI-Komponenten, Tailwind CSS sorgt für konsistente Gestaltung, und mit TypeScript und Vitest habe ich Typisierung und Tests auf Augenhöhe mit jedem React-Setup.
Auf der Backend-Seite kann ich ein API, das nur für das Frontend gedacht ist, gleich ganz einsparen und eine Mustache Template Engine direkt auf den Value Objects herumtanzen lassen, die vom Application Service der DDD-Anwendung geliefert werden. Nice!
Die selbst erfüllende Prophezeiung: React everywhere
Ein besonders frustrierendes Problem ist der Feedback-Loop, den React inzwischen ausgelöst hat: Unternehmen setzen React ein, weil sie dafür Entwickler finden. Entwickler lernen React, weil sie denken „damit kriege ich am ehesten einen Job“. Neue Teams setzen React ein, weil „alle das machen“. So entsteht ein Kreislauf, in dem Innovation kaum noch eine Chance hat.
Ich habe Gespräche erlebt, in denen Teams gerne etwas Neues ausprobieren wollten – etwa Web Components oder serverseitiges Rendering mit HTMX – aber dann hieß es: „Wir finden halt nur React-Entwickler.“ Das mag stimmen, aber es liegt auch daran, dass kaum jemand öffentlich zeigt, wie gut moderne Alternativen funktionieren können.
Dabei wäre der Umstieg oft gar nicht so groß. Die meisten Entwickler verstehen HTML, CSS und JavaScript. HTMX und Lit bauen genau auf diesen Technologien auf. Man muss ein wenig „verlernen“ und unnötigen Overhead abwerfen.
React ignoriert den Browser – HTMX und Lit tun das Gegenteil
Ein weiterer Aspekt, der mich zunehmend stört, ist Reacts Verhältnis zu Webstandards. Statt mit dem Browser zu arbeiten, abstrahiert React vieles weg. Custom Elements? Unzuverlässig. Formularverhalten? Selber bauen. Navigation? Komplett ersetzt.
HTMX geht den anderen Weg: Es nutzt ganz bewusst HTML und HTTP so, wie sie gedacht sind. Es bringt den Gedanken von Hypermedia zurück – und das auf eine Art, die moderne Webanwendungen nicht verkompliziert, sondern vereinfacht. Lit wiederum zeigt, wie elegant sich Komponenten bauen lassen, wenn man dem Browser vertraut.
Mein Fazit nach sechs Jahren React: Es geht auch anders – und besser
Ich will React nicht verteufeln. Es ist eine mächtige Bibliothek, und in bestimmten Projekten nach wie vor sinnvoll. Aber ich glaube, dass wir als Community gut daran tun würden, die Werkzeuge bewusster auszuwählen – und öfter mal aus der Bubble auszubrechen. Nicht jedes Projekt braucht eine SPA. Nicht jeder UI-State muss clientseitig verwaltet werden. Und nicht jede Webanwendung muss gleich wie eine native App funktionieren.
Ich habe den Schritt raus aus React gewagt – und seitdem produktivere, verständlichere und nachhaltigere Anwendungen gebaut. Vielleicht ist es Zeit, dass wir den Mut aufbringen, unsere Standards zu hinterfragen. So wie wir es bei jQuery irgendwann auch getan haben.
Danke an Rahul Mishra für das schöne Titelfoto, das man auf Unsplash finden kann!