Die Ermüdung durch Abhängigkeitsmanagement: Warum ich React aufgegeben und mich für Go+HTMX+Templ entschieden habe

• Nachdem ich dieses Jahr ein persönliches Projekt mit Go, HTMX und Templ umgesetzt hatte, beschloss ich, React nicht mehr zu verwenden
  • Auf der offiziellen HTMX-Website finden sich mehrere überzeugende Argumente dafür, React aufzugeben und HTMX zu wählen, aber ich hatte das Gefühl, dass kaum jemand über die Ermüdung durch Abhängigkeitsmanagement spricht
• Was ist „Ermüdung durch Abhängigkeitsmanagement“?
  • Bei meinem letzten persönlichen Projekt mit React (ein interaktives katalanisches Wörterbuch) wurde mir klar, dass ich zu viel Zeit für das Aktualisieren der Abhängigkeiten von React-Paketen aufwende
  • Wenn ich Pakete auf die neueste Version aktualisierte, führten tiefgreifende API-Änderungen dazu, dass ich Zeit in Refactoring des Codes investieren musste
  • Da die Web-App als öffentlicher Dienst auf einer EC2-Instanz bereitgestellt wurde, wollte ich die Abhängigkeits-Updates pflegen
• Sind neue Major-Releases wirklich nötig?
  • Pakete wie wouter (ein React-Router-Paket) und TanStackQuery (verwendet, um Daten aus dem Backend zu laden und zu cachen sowie den Status zu verwalten) haben die Web-App durch Major-Updates schwer beschädigt.
  • Als die Anwendung durch das erste Major-Update kaputtging, habe ich den Code ohne Zweifel refaktoriert, aber als es ein zweites Mal passierte, kamen Zweifel auf
  • Ich fragte mich, welchen tatsächlichen Nutzen die Web-App aus Major-Releases zieht, abgesehen von Sicherheits-Patches
  • Ich fragte mich, ob es wirklich nötig ist, die API zentraler Komponenten gleich fünfmal zu brechen
  • Ich dachte darüber nach, wie viel Zeit ich dadurch verliere, in der ich neue Funktionen oder andere Produkte veröffentlichen könnte
• Das Problem des Zeitmangels
  • Da ich nicht viel Zeit für persönliche Coding-Projekte habe, möchte ich keine Zeit damit verschwenden, nach Major-Updates von Abhängigkeiten den Code zu refaktorieren
  • Wenn ich ein Produkt für Kunden bauen und für künftige Wartungsarbeiten Geld verlangen wollte, wäre es in Ordnung, viele instabile Abhängigkeiten zu nutzen
  • Wenn ich jedoch ein Produkt mit minimalem Wartungsaufwand bauen möchte, würde ich mich vom JS-Ökosystem möglichst fernhalten
• Einsatz von Go+HTMX+Templ
  • Der Hauptgrund, warum ich in persönlichen Projekten Go+HTMX+Templ einsetze, ist, dass Go-Projekte es mir ermöglichen, mich auf das Veröffentlichen von Funktionen zu konzentrieren, ohne dabei normale Abhängigkeits-/Sicherheits-Updates zu ignorieren
  • Die Sprache Go selbst bewahrt eine stabile Standardbibliothek und Sprachspezifikation

[bbulbum]

HTMX scheint viele positive Bewertungen zu bekommen.
Ich frage mich, ob viele HTMX als Ergänzung für SSR-basierte Anwendungen suchen.
Ich sollte es einmal nebenbei ausprobieren.

[savvykang]

Ich habe mich nicht für die TanStack-Bibliotheken entschieden, weil sie unnötig komplex sind und die Qualität der Dokumentation in den letzten Jahren nachgelassen hat. Außerdem ist der Austauschzyklus von npm-Paketen so kurz, dass ich mich frage, ob man wirklich immer auf der neuesten Version bestehen muss.

Allerdings wird man bei der Arbeit im Unternehmen wohl nicht auf React verzichten können. Bei einem privaten Projekt ist es dagegen egal, was man verwendet.

[dohyun682]

Gibt es nicht eigentlich kaum größere Probleme mit Abhängigkeiten, solange man keine Major-Version-Updates macht ...?

[aer0700]

Vor Kurzem habe ich unter den intern laufenden Scheduler-Jobs einen entdeckt, der noch mit Python 2 läuft, und mir blieb fast die Luft weg.
Nach einigem Überlegen haben wir beschlossen, ihn erst einmal so zu lassen, weil er im Moment problemlos läuft. Auf Dauer wird man aber nicht ewig ohne Updates durchhalten können.

[aer0700]

Die Ermüdung durch Dependency-Management vs. der Überdruss daran, das Rad neu zu erfinden
Eine alte Debatte. Unnötige Räder nicht zu benutzen ist zwar richtig, aber ob etwas, das man heute nicht braucht, auch morgen noch unnötig ist ...
Ich habe Go zwar noch nie verwendet, aber in letzter Zeit sehe ich viele mit Go gebaute Server. Auch wenn ich es nicht sofort einsetze, sollte ich es wohl wenigstens einmal ausprobieren.

[clickin]

HTMX ist wohl an der Spitze der hippen Technologien, deshalb probieren es so viele aus, aber ich frage mich, ob nicht eher eine Richtung wie Go + Vecty + gox sinnvoller wäre.

[GN⁺]

Hacker-News-Kommentare

• Es wird die Erfahrung geteilt, bei der Entwicklung von Web-Apps auf Bibliotheken wie React zu verzichten und stattdessen Actix, Tera und HTMX zu verwenden. Dieser Stack sei gut wartbar und komme bei Nutzern gut an.

  • Beschrieben wird die Erfahrung, eine neue Web-App schnell zu entwickeln und an Testnutzer auszurollen.
  • Da es keine „Müdigkeit durch Dependency-Management“ gab, konnte ein tiefes Verständnis der Werkzeuge aufgebaut werden.

• Tanners Bibliotheken werden als funktionsreich, aber mit schwachem API-Design bewertet.

  • React Table und React Query seien leistungsfähig, verursachten aber Probleme, weil ihre Grenzen falsch gezogen seien.
  • Der Vorteil von React sei, dass es kein Framework ist und an gut gestalteten Grenzen stoppt.
  • Es werde versucht, nur Bibliotheken zu übernehmen, die diese Kriterien erfüllen.

• Es wird erklärt, dass HTMX-Beispiele die Komplexität nur an andere Stellen verschieben und dass JSX ein eleganter Weg sei, Templates zu vermeiden.

  • Routing, State-Management, Authentifizierung und andere Probleme müssten weiterhin gelöst werden.

• Es wirke seltsam zu sagen, man gebe React auf; das Problem liege nicht bei React, sondern bei anderen Abhängigkeiten.

  • Die Wahl, das Backend in Go zu schreiben, sei immer möglich gewesen.

• Es wird betont, dass man bei einem Update auf die nächste Major-Version eines Pakets mit Änderungen rechnen sollte.

  • Am Beispiel von Remix wird erklärt, wie sich Änderungen schrittweise übernehmen lassen.
  • Es wird argumentiert, dass gute Pakete großen Aufwand erfordern.

• Es wird die Erfahrung geteilt, ein SPA-Projekt mit Django und HTMX migriert und die JavaScript-Abhängigkeiten stark reduziert zu haben.

  • Das SPA habe sich wie eine Zeitbombe angefühlt.

• Es wird argumentiert, dass React nicht für schlecht gepflegte Third-Party-Pakete verantwortlich sei.

  • Es wird erklärt, dass weder ein Router noch State-Management-Tools wie Redux nötig seien.

• Es wird die Ansicht vertreten, dass v5 von react-query mit der API von v3 kompatibel hätte sein sollen, zugleich wird erklärt, dass die Migration einfach und nicht zwingend sei.

  • Die „Müdigkeit durch Dependency-Management“ werde als übertrieben empfunden, und es wird geraten, die Zahl der Abhängigkeiten vernünftig zu halten.

• Es wird infrage gestellt, warum ein Upgrade durchgeführt wurde, obwohl die Web-App dadurch keinen zusätzlichen Nutzen erhalten habe.

  • Es wird erklärt, dass ein Upgrade auf die neueste Version keinen Vorteil bringe.

• Es wird beschrieben, dass nach dem Verzicht auf React und nextjs zugunsten eines anderen Stacks der Stress abgenommen habe und Updates keine Depressionen mehr auslösten.