htmx statt React klingt nach Rückschritt und ist bei der Forensoftware Misago eine bewusste Architekturentscheidung. Das Django-Projekt entfernt React aus der Codebasis und ersetzt die Interaktivität durch serverseitig gerenderte HTML-Fragmente. Für Teams, die eine Single-Page-Anwendung pflegen, ohne je eine gebraucht zu haben, lohnt der Blick auf die Begründung.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Interaktivität sitzt nur an wenigen Stellen
Der ursprüngliche Plan sah die klassische Trennung vor. Django liefert eine API, das Frontend läuft als React-Anwendung, wahlweise mit serverseitigem Rendering über Next.js oder Remix. Beim Nachrechnen fiel dem Projekt allerdings auf, wie punktuell die Interaktion in einem Forum tatsächlich stattfindet.
Moderationsaktionen, das Beobachten eines Themas, das Schreiben einer Antwort, Benachrichtigungen und Umfragen decken den größten Teil ab. All diese Funktionen liefen jahrelang ohne Framework, bevor der vollständige Seitenwechsel als Makel galt. Die Projektdokumentation nennt die Umstellung auf htmx deshalb den passenden Weg für Forensoftware.
Inseln statt Anwendung
htmx markiert einzelne HTML-Bereiche als dynamische Inseln, die der Server bei einer Interaktion neu ausliefert. Die Themenliste bildet eine solche Insel. Ein Kategoriewechsel holt nur den neuen Listenabschnitt nach, während bereits geladene Suchergebnisse in der Navigation unangetastet bleiben.
Im Backend entfällt damit die Serialisierung nach JSON. Django gibt bei einer htmx-Anfrage schlicht das Teil-Template zurück statt der kompletten Seite. Der Projektgründer vergleicht das Muster offen mit dem, was vor zwanzig Jahren ein jQuery-Aufruf auf ein Ziel-Element erledigte. Die Themenlisten hat das Projekt auf dieser Basis bereits von Grund auf neu gebaut.
Wo der Rückbau trägt und wo nicht
Ehrlich bleibt die Rechnung nur mit ihrer Kehrseite. Ein Server, der Fragmente rendert, trägt mehr Last, und jede Interaktion kostet einen Netzwerkweg. Kollaborative Editoren, Drag-and-drop-Oberflächen, Canvas-Werkzeuge und alles mit Bildwiederholrate bleiben Aufgaben für ein Client-Framework.
Bei internen Werkzeugen, Verwaltungsoberflächen und inhaltsgetriebenen Seiten dreht sich das Bild. Dort verschwinden Zustandsverwaltung und Hydration ersatzlos, dazu ein zweiter Deployment-Pfad samt eigener Abhängigkeitspflege.
Ein Framework-Rückbau macht kein Projekt automatisch schneller. Teams, die eine Zustandsverwaltung im Browser pflegen, obwohl der Server die Wahrheit ohnehin allein hält, bezahlen dafür in jedem Sprint mit Wartungszeit.
— Michael Dobler, Herausgeber Dr. Web
Was Sie im eigenen Stack prüfen sollten
Zählen Sie die Stellen in Ihrer Anwendung, an denen der Browser wirklich eigenen Zustand hält. Bleibt die Liste kurz, trägt ein serverseitiger Ansatz die Oberfläche vermutlich genauso gut. Passende Helfer für die Umbauphase sammelt unsere Übersicht der Webdesign-Tools für den Alltag, und der Vergleich der führenden Programmiersprachen ordnet den Serverpart ein.
