Das Frontend-Laufband
(polotek.net)- Je langlebiger ein Produkt ist, desto höher werden die Kosten durch die Zeit und Energie, die in Debatten über Neuschreibungen fließen, als durch die Wahl des Frontend-Frameworks selbst
- Wenn ein Produkt in fünf Jahren noch lebt, ist das ein Erfolg, doch in dieser Zeit ist das gewählte Framework mit hoher Wahrscheinlichkeit veraltet oder hat sich unter demselben Namen in einer neuen Version stark verändert
- Bessere Produktteams wechseln nicht einfach zu neuen Tools, sondern verstehen ihr aktuelles Framework in der Tiefe und bauen genug Kompetenz auf, damit das Tool den Arbeitsfortschritt nicht behindert
- Um langfristige Kosten zu senken, kann eine Entscheidung näher an der Web-Plattform und den zentralen Webtechnologien statt an komplexen Abstraktionen ein realistischer geschäftlicher Kompromiss sein
- Die Komplexität des Frontend-Ökosystems erschwert sowohl Berufseinsteigern als auch Hiring-Teams die Arbeit, und Entwickler mit schwachen Web-Grundlagen sind dem nächsten Stack-Wechsel stärker ausgeliefert
Mit Neuschreibungen kommt man kaum vom Laufband herunter
- Viele Frontend-Teams glauben, dass eine Neuschreibung zu einem besseren Zustand führen wird, doch bei langlebigen Produkten ist nicht die Wahl des Frameworks selbst die wichtigste technische Entscheidung
- Wenn ein Produkt länger als fünf Jahre besteht, kann man das als Erfolg ansehen, doch in dieser Zeit kann das gewählte Framework veraltet sein
- Die Frontend-Community war schon immer von Veränderungen getrieben, und es ist unwahrscheinlich, dass sich das in naher Zukunft ändert
- Selbst erfolgreiche populäre Frameworks können sich intern vollständig verändern und unter einer neuen Versionsnummer praktisch neu geschrieben werden
- Worauf sich Teams konzentrieren sollten, ist nicht die Jagd nach neuen und glänzenden Tools, sondern das Framework, das sie jetzt verwenden, ausreichend gut zu beherrschen
- Es braucht genug Verständnis und Übung, damit das Tool nicht zum Hindernis für den Arbeitsfortschritt wird
- Die Erwartung, dass ein Wechsel zu einem alternativen Tool die Probleme lösen werde, ist fast schon eine Falle
Näher an der Web-Plattform sinken die langfristigen Kosten
- Unternehmen, die die Kosten häufig veraltender Frontend-Technologien senken wollen, können einen Weg näher an der Web-Plattform prüfen
- Das bedeutet, komplexe Abstraktionen zu reduzieren und neu zu lernen, wozu das Web tatsächlich in der Lage ist
- Das heißt nicht, dass dies die Antwort auf alle Probleme ist oder zwangsläufig besser wäre
- Es kann ein geschäftlicher Kompromiss sein, der langfristig mehr Wert schafft und die Kosten senkt
- Wer näher an den zentralen Webtechnologien bleibt, lässt sich bei der künftigen Einstellung fähiger Engineers weniger von Behauptungen treiben, man könne nur arbeiten, wenn man erst Millionen Zeilen Code neu schreibt
- Auch für einzelne Engineers ist ein tiefes Verständnis der zentralen Webtechnologien langfristig wertvoller für den Markt als das ständige Mitziehen mit einem bestimmten Framework
- Dafür kann man kurzfristig auf einen Teil der unmittelbaren Attraktivität am Arbeitsmarkt verzichten
- Für die Beständigkeit der Karriere ist es vorteilhafter, als zu versuchen, jede populäre Technologie zu lernen
- Das Wissen über eine bestimmte Technologie schützt einen nicht vor Realitäten wie einer Verschlechterung des Marktes
Framework-Präferenzen und Teamkosten
- Engineers mit starken Framework-Präferenzen sollten diesen Maßstab in ihre Jobsuche einfließen lassen
- Wenn man erst in ein Team eintritt, das bereits ein bestimmtes Framework nutzt, und dann versucht, es auf das bevorzugte Framework umzustellen, destabilisiert das das Team und erhöht die Kosten erheblich
- Die aktuelle Komplexität des Frontend-Ökosystems belastet sowohl Berufseinsteiger als auch Unternehmen
- Berufseinsteiger tun sich schwer damit, genug Fähigkeiten für den Berufseinstieg zu erwerben, und fühlen sich von komplexen Tools überfordert
- Unternehmen empfinden selbst die Einstellung allgemeiner Entwickler als schwieriger, und die Eintrittshürden für reguläre Entwicklerrollen steigen
- Wer das heutige Technologie-Ökosystem lernt, aber keine Web-Grundlagen erwirbt, kann beim nächsten Stack-Wechsel in eine gravierende Benachteiligung geraten
- Das Web ist eine leistungsfähige und einzigartige Plattform zur Auslieferung von Software; es ist mit der Zeit besser geworden und hat ein hohes Maß an Abwärtskompatibilität bewahrt
- Die grundlegenden Werkzeuge von heute sind gut genug, doch die Framework-Schicht arbeitet gegen die Plattform, statt sie anzunehmen
1 Kommentare
Meinungen auf Hacker News
Ich habe kürzlich das Build-System unseres Frontend-Codes von yarn auf pnpm umgestellt. Normalerweise bin ich Backend-Engineer, habe aber auch einiges mit JS gemacht.
Was mich beim Einstieg ins Frontend am meisten nervt: Es wirkt wirklich so, als sei alles deprecated. Wenn man 2022 die apollo CLI benutzt hat, ist sie sofort deprecated, und man muss ein völlig anderes Tool wie graphql-client mit ganz anderen Einstellungen und Optionen lernen. Am Ende haben wir das Alte beibehalten und nur die Node-Engine-Prüfung von pnpm deaktiviert, damit es nicht meckert. Wenn man versucht, eine Dependency per Patch-Upgrade zu aktualisieren, können Type-Signaturen brechen; also pinnt man auch das und hinterlässt im Codebase ein TODO in der Hoffnung, dass es irgendwann jemand behebt.
Sobald man es gerade so zum Laufen gebracht hat, rauschen während der Installation Hunderte Deprecated-Warnungen vorbei, und sobald der Build fertig ist, will man nur noch fliehen.
Es fühlt sich wirklich seltsam an, in welchem Maß die gesamte Frontend-Entwicklung Breaking Changes und Deprecations einfach hinnimmt. Ich arbeite seit fast vier Jahren an einem großen Rust-Projekt; in der Zeit gab es ein paar kleine Breaking Changes in Third-Party-Libraries, aber nur eine größere Änderung, wegen der wir die Anwendung nennenswert umbauen mussten. Bei JS dagegen wirkt es, als müsse man nach nicht einmal sechs Monaten wieder irgendetwas neu schreiben.
Die Frontend-Welt hat Social Media, YouTube und sogar Twitch viel aktiver angenommen als andere Bereiche. Diese Influencer brauchen ständig neues Material, um relevant zu bleiben, also pushen sie ununterbrochen neue Dinge, aus denen man Content machen kann.
Dazu kommt eine lebendige Konferenzkultur. Frontend- und JS-Konferenzen fühlen sich an wie ein großer Wettbewerb darum, das nächste heiße Thema vorzustellen.
Auch der Markt für Frontend-Kurse ist groß. Kursanbieter müssen Vorgesetzte dazu bringen, einen zeitlich begrenzten Videokurs für 700 Dollar zum Lernen des neuesten Trends abzusegnen. Dafür muss sich die Branche von dem entfernen, was ohnehin schon alle kennen. Also wird das Neue stark gepusht und das Alte deprecated.
Eine kleine 5-KLOC-Webapp in reinem JS, die ich vor 15 Jahren geschrieben habe, wird heute noch täglich von etwa zehn Leuten genutzt, ohne dass eine einzige Zeile geändert wurde. Sie hält sich eher besser als eine Win32-Anwendung.
Der Großteil des Churns im Frontend ist meiner Ansicht nach schlicht eher ein politisches bzw. organisatorisches Versagen.
Als ich in der Zeit von reinem JS/jQuery angefangen habe, bedeutete Dependency-Management praktisch,
.js-Dateien in einvendor/-Verzeichnis zu kopieren. Danach kamen nodejs/npm, im Frontend wurde vor npm auch bower genutzt, und plötzlich wurde der Rat, lieber Module herunterzuladen statt selbst etwas zu bauen, zum Standard.Aber schon damals fragten sich viele, ob es wirklich richtig ist, Tausende Zeilen versteckten Code nicht selbst zu besitzen, sondern Freiwilligen zu überlassen, die Open Source zum Spaß machen.
Auch heute kann man, wenn man ein Projekt lange erhalten will, vermeiden, die unsichtbaren Teile zu sehr aufzublähen. Kleine Probleme lassen sich so behandeln: „Ich brauche aus dieser Library nur eine Funktion, also hängen wir nicht die ganze Library als Dependency dran, sondern kopieren nur diese Funktion in die Codebase und schreiben Tests dafür.“
Deshalb sehe ich das nicht als Problem von JavaScript selbst, sondern als Problem von Menschen und Prozessen. Es gibt viele JS-Entwickler, die diese Probleme nicht haben, aber ein großer Teil des Ökosystems hat sie eben doch.
Jeden Tag werden Tausende Personenstunden damit verbracht, die Folgen „sehr wichtiger“™ Breaking Changes zu beheben, etwa: „Wie wäre es, wenn wir MultiselectDropdown in MultiSelectButtonDropdown umbenennen? Und die API gleich komplett neu machen!“
Es gibt kaum eine Kultur, die die enormen Kosten brechender APIs versteht. Nach zehn Jahren Go ist das besonders frustrierend. Go hat ein Abwärtskompatibilitätsversprechen, und das scheint auch die Haltung von Go-Library-Entwicklern zu Kompatibilität und Breaking Changes zu prägen. Es ist eine wirklich gute Erfahrung, wenn Code von vor zehn Jahren mit dem aktuellen Go unverändert kompiliert und läuft.
Ich bin auch einmal zu Flutter gewechselt, um dieser JS-/Web-Hölle zu entkommen; das hat ziemlich gut gepasst, und ich konnte einen Großteil der zufälligen Komplexität des Web-Stacks vergessen. Aber die Kultur „Pakete zu brechen ist okay“ sickert auch in das Dart-Ökosystem ein, was extrem nervig ist.
Ehrlich gesagt finde ich es deutlich schlimmer als Frontend. Im Frontend halten TypeScript und die Spracheigenschaften den Schadensradius immerhin auf einem relativ vernünftigen Niveau. In Python kann man wirklich buchstäblich alles tun, und deshalb tun Library-Autoren auch buchstäblich alles. Wenn sie die Art ändern wollen, wie Module importiert werden, ändern sie sie; wenn sie mit Metaklassen jede Annahme über das Verhalten von Klassen brechen wollen, können sie das. Selbst wenn man glaubt, statische Typen würden helfen: Nicht einmal Kleinigkeiten wie
Partialfunktionieren, und man kann statisch auch nicht behaupten, dass zwei Objekte denselben Typ haben.Es ist lustig, Leute darüber klagen zu sehen, dass sich Libraries ändern. Der Wechsel von Python 2 zu 3 war so furchtbar, dass es bei meinem früheren Arbeitgeber einen Python-Monolithen mit 100 Millionen Zeilen gab, für den es keinerlei Plan gab, jemals auf Python 3 zu upgraden. Der Umstieg von SqlAlchemy 1 auf 2 ist eine achtstufige Migration und praktisch ein kompletter Rewrite; wenn dabei auch nur eine Sache kaputtgeht, ist die Site down. Und dann beschwert man sich darüber, dass React optional Hooks hinzugefügt hat.
Seltsam ist, dass das Internet voller Artikel über die „Frontend-Tretmühle“ ist, man aber kaum Texte findet, die sich über die andere Seite beschweren.
Zur Aussage „Wenn man als Engineer die zentralen Web-Technologien gründlich versteht, kann man seinen Marktwert im Lauf der Zeit deutlich besser halten“: Ich mache seit fast 20 Jahren Frontend und habe mehrere große Paradigmenwechsel erlebt, daher denke ich, dass ich dazu etwas sagen kann.
Wenn man alle grundlegenden Web-Technologien kennt, wird man definitiv ein ausgewogenerer Engineer. Aber ich bin skeptisch, ob einen das auf dem Arbeitsmarkt attraktiver erscheinen lässt. Nicht weil dieses Wissen unwichtig wäre, sondern weil die Entscheider im Recruiting meist Pattern Matching betreiben.
Wenn man seinen „Marktwert“ maximieren will, muss man weiterhin sehr gut in React sein. Das ist eher die Eintrittskarte; der Rest ist großartig, aber ohne diese Grundlage werden die Optionen weniger. Vielleicht meinte der Autor genau das und ich habe es nur falsch gelesen.
Bei Consulting- oder Vertragsrollen stimme ich dem ursprünglichen Kommentar allerdings zu. Wenn man in einer großen Beratung mit Leuten zusammenarbeitet, die einstellen oder entscheiden, wer überhaupt zum Interview kommt, merkt man: Wer ihren bevorzugten Stack oder den Stack, den der aktuelle Kunde nutzt, nicht bereits kennt, wird fast automatisch aussortiert. Das gilt auch für technische Architekten, es ist also nicht nur ein Problem nichttechnischer Recruiter. Unabhängig vom Können wollen sie keine Zeit dafür einplanen, dass sich jemand erst an die Technologie selbst anpasst.
In solchen Rollen ist es sehr wichtig, ständig auf dem neuesten Stand zu bleiben. Sonst wirft der Hiring Manager den Lebenslauf wegen fehlender Buzzwords weg, noch bevor ein Engineer die Fähigkeiten bewerten kann.
Vielleicht bin ich ein Sonderfall, aber dass ich React nicht kannte, war nie ein Problem. „Eintrittskarte“ ist eine zu starke Formulierung.
Im Frontend gibt es eine ziemlich feste Obergrenze bei der Vergütung. Wenn man über ein bestimmtes Niveau hinauskommt, muss man nie wieder UI bauen.
Die meisten Unternehmen, selbst große, kümmern sich nicht groß um die Grundlagen, prüfen sie nicht ernsthaft und stellen auch nicht danach ein. Sie stellen nach Kriterien wie „gut in React“ oder „viel Next.js-Erfahrung“ ein.
Grundlagen sind großartig, wenn man von Grund auf etwas baut, aber in realen Unternehmen passiert das kaum. Meist nimmt man fertige Lösungen mit großem Ökosystem und guter Dokumentation. Wenn man damit gut umgehen kann, wird man viel leichter eingestellt, und die Grundlagen kann man dabei lernen.
Die Aussage „Egal welches Framework man wählt, in 5 Jahren ist es obsolete“ wirkt wie ein etwas veraltetes Argument.
Ich bin zwar nicht hauptsächlich Frontend-Entwickler, aber ich meide Frontend nicht, wenn es anfällt, und habe in den letzten etwa 10 Jahren React verwendet. Ein Teil der Stimmung verschiebt sich zu Svelte, aber bis Svelte React überholt, wird Svelte vermutlich ebenfalls schon entsprechend lange in Produktion eingesetzt worden sein. Auch Angular könnte irgendwann an Kraft verlieren, aber wenn man die Zeit von Angular1 und Angular2+ zusammen betrachtet, ist es älter als React.
Frontend-Entwicklung bewegt sich schnell, ja, aber so schlimm ist es nicht. Wenn man langweilige Entscheidungen trifft, bekommt man langweilige Ergebnisse.
Angular1 und 2 waren abgesehen vom Namen kaum vergleichbar, und viele Entwickler haben sich daran die Finger verbrannt. Auch Angular selbst verändert sich ziemlich stark. Es ist nicht so extrem wie der Wechsel von v1 zu Angular2, erfordert aber dennoch eine erhebliche Umgewöhnung. Alles bewegt sich in Richtung standalone components, neue Template-Syntax, signals usw.
Bei React ist es ähnlich. Mit funktionalen Komponenten und Hooks gab es einen großen Paradigmenwechsel. Es war kompatibel, aber sehr unterschiedlich.
Dasselbe gilt für die allgemeineren Paradigmen. Anfangs war alles serverseitig gerendert, dann sprintete man mit voller Kraft zu Single-Page-Apps, und nun ist man wieder bei serverseitigem Rendering angekommen, diesmal aber als partielles serverseitiges Rendering mit Hydration.
Es ist so anders, dass man es fast ein anderes Framework nennen könnte; mit etwas Nuance ist das Argument also nicht völlig tot.
Es ist wirklich einfach, damit zu arbeiten. Ich habe eine einfache App zur Aktienallokation gebaut, und am meisten überrascht hat mich die Bundle-Größe. Sie lag bei 9 KB mit gzip und ist kleiner als bei jedem Framework, das ich kenne. Sogar kleiner als htmx, das gewissermaßen schon ziemlich „anti-JS“ ist.
Alte Frameworks kann man sehr lange betreiben. Wenn es Leute gibt, die diesen Stack kennen, und man sie bei Bedarf einstellen kann, um daran zu arbeiten, ist dieser Stack nicht obsolete. „Alt“ oder „Legacy“ kann zutreffen. Aber bis zu dem Tag, an dem niemand mehr übrig ist, der damit umgehen kann, ist er nicht obsolete.
Interessant, das als Frontend-Problem zu bezeichnen. Es ist kein Frontend-Problem, sondern ein Problem, bei dem ständig neue Teilnehmende in ein riesiges Ökosystem hinzukommen.
Dasselbe habe ich vor 15 Jahren gesehen, als Java an der Spitze der Innovation stand. Innerhalb weniger Jahre kamen Dutzende Frameworks und mehrere Build-Systeme heraus. Der Wechsel von React 17 zu 18 ist eine deutlich kleinere Veränderung als von Perl 5 zu 6 oder von Python 2 zu 3.
Im Backend heißt es statt „Nehmen wir ein neues Framework“ eher „Nehmen wir eine neue Sprache“. Der aktuelle Trend ist, Dinge in Rust neu zu schreiben; davor gab es Go, Haskell, Scala und F#.
Wenn man es lästig findet, Frontend-Code von React auf etwas wie Svelte zu migrieren, sollte man einmal versuchen, eine VB-6-App neu zu schreiben. Von Dingen wie RPC, bei denen die Daten im Code stecken, ganz zu schweigen.
Das heißt nicht, dass die Instabilität von Engineering-Praktiken kein Problem wäre. Sie ist ein großes Problem. Nur eben keines, das allein das Frontend betrifft.
webpack ist ebenfalls 13 Jahre alt, aber selbst in den letzten Jahren hat sich die Art der Konfiguration drastisch verändert.
Wenn sich die Apache-Konfiguration so häufig ändern würde wie bei diesen Systemen, würde niemand Apache verwenden.
Bei meinem vorherigen Arbeitgeber gab es innerhalb von zwei Jahren zwei Datenbankmigrationen, die insgesamt ein Jahr Engineering-Zeit verschlangen. Es ging nicht um ein paar unwichtige Tabellen, sondern um alle Tabellen. Wenn etwas kaputtging oder das Management fragte, warum alles so langsam sei, gab man den Engineers die Schuld, die Frontend lernten, weil sie angeblich zu wenig Erfahrung hätten.
Ich arbeite seit über 25 Jahren als Java-Entwickler; in den ersten gut zehn Jahren habe ich Full-Stack entwickelt, was damals in den Unternehmen die übliche Form war. Heute ist es normal, ein eigenes Frontend-Team zu haben, oft sogar drei Teams für Web, iOS und Android. Für mich passierte diese Veränderung ungefähr in der Zeit des Wechsels von AngularJS zu Angular.
Auch Java veränderte sich in den ersten etwa zehn Jahren schnell, besonders in den ersten drei Jahren sehr schnell. Aber diese Phase ist vorbei. Java 5 war eine große Veränderung, und Java 8 brachte ebenfalls wichtige Features, aber Java 8 ist von 2014. Unser Team ist erst kürzlich auf Java 11 gewechselt, und inzwischen ist Java 24 erschienen. Ich habe nie Java-11-Features verwendet und weiß nicht einmal, welche das sind. In zehn Jahren habe ich keine einzige neue Sprachfunktion gelernt.
Die Build-Tools sind seit 15 Jahren dieselben, die IDE seit 20 Jahren. Auch das hauptsächlich verwendete Framework ist seit 10 Jahren dasselbe. Als ich zu meinem letzten Arbeitgeber wechselte, war die Struktur der Codebasis exakt dieselbe wie im vorherigen Team.
Webservices mit Java zu bauen ist ein gelöstes Problem. Im positiven Sinne völlig langweilig, fast wie COBOL.
Frontend veränderte sich schon Ende der 90er- und Anfang der 2000er-Jahre schnell, und seitdem hat es sich weiter schnell verändert. Ein privates UI-Projekt, das ich vor ein paar Jahren gebaut habe, ist inzwischen völlig veraltet.
Bei Java-Projekten, an denen ich nach der EJB-Ära gearbeitet habe, könnte man heute einen Java-Entwickler dazuholen und er wäre sofort produktiv. Selbst wenn dieser Entwickler erst nach Entstehung des Projekts geboren wurde. Es gäbe nur ein paar alte Libraries zu lernen.
Der Weg vom Laufband herunter besteht darin, überhaupt kein Frontend-Framework zu verwenden. Nicht darin, irgendein anderes Framework auszuwählen und es später erneut umzuschreiben.
Es braucht Server-Side Rendering, JavaScript nur dann, wenn es nötig ist, und innerhalb des Unternehmens keine Trennung von Backend- und Frontend-Personal.
Wenn ein Engineer SQL schreiben kann, das genau die Spalten abruft, die für eine SSR-Web-View nötig sind, und zugleich für diese Web-View verantwortlich ist, muss man sich keine Sekunde mit Dingen wie APIs oder ORMs beschäftigen. Man muss nur SQL und modernes, reines HTML/CSS/JS kennen. Der Großteil der Arbeit besteht dann darin, Views des Geschäfts (SQL) in das DOM (HTML) zu transformieren, während das serverseitige Programmierökosystem in den Hintergrund tritt.
Die Endform sehe ich darin, Webinhalte innerhalb des RDBMS per SSR zu erzeugen. So wie bei Oracle APEX. Aber die meisten Engineers sind für dieses Gespräch noch nicht bereit. Ich war es auch nicht, als ich es zum ersten Mal in der Praxis sah. Wir hängen zu sehr an unseren Arten zu leiden.
Sie hat das Problem übermäßiger Frontend-Komplexität verschärft. Da im Frontend-Team Leute sitzen, schaffen sie sich weiter Arbeit und fügen Komplexität hinzu. Ein weiteres Problem ist, dass es zu viele Menschen gibt, die nur Webentwicklung kennen und sonst nichts.
Bei einem Nebenprojekt habe ich als eine der frühen Einschränkungen festgelegt, dass die gesamte Site auch bei deaktiviertem JavaScript elegant degradieren soll. Dadurch fragte ich mich jedes Mal, wenn ich eine Funktion hinzufügen wollte, die man normalerweise mit JavaScript umsetzen würde: „Geht das auch ohne JavaScript?“ — und bisher lautete die Antwort überraschenderweise immer ja.
Allein mit CSS-Selektoren für grundlegende HTML-Controls kann man heute wirklich viel machen. In dieser Codebasis gibt es noch keine einzige Zeile JS.
Produkt- und Designteams können darauf drängen, so viel JavaScript-Dekoration wie möglich einzubauen, ohne Usability, Performance, Barrierefreiheit oder gutes Engineering auch nur im Geringsten zu berücksichtigen.
Ich bin nicht gut im Frontend, und wir haben auch keinen Designer. Im Backend bin ich deutlich besser, aber andere im Team haben mehr Talent für Frontend-Design als ich.
Als ich meine erste Website gebaut habe, las ich Artikel wie „Svelte ist besser als React“ oder „solid-js wird das nächste große Ding“ und dachte, das sei ein wichtiger Teil der Webentwicklung.
Anfänger sollten MDN lesen und den Rest ignorieren.
Menschen brauchen Tutorials und Walkthroughs und müssen ein internes Verständnis dafür aufbauen, wie all das funktioniert.
Frameworks helfen dabei, solche Dinge zu abstrahieren.
Aber die jüngste Fixierung auf Next.js und SSR vielleicht nicht. Persönlich glaube ich, dass das sogar ein Grund für den Niedergang auf der React-Seite werden könnte.
Wenn man bedenkt, wie sehr sich reines JS und CSS in den letzten Jahren weiterentwickelt haben, und dass interessante Funktionen wie Animationen für
display: nonefast vor der breiten Einführung stehen, wirkt der Ansatz, HTML-Templates auf dem Server zu erzeugen und JS nur dort einzusetzen, wo es nötig ist, plausibler denn je.Das sage ich als jemand, der seinen Lebensunterhalt hauptsächlich mit React verdient.
Wie der Autor mache auch ich seit 20 Jahren auf die eine oder andere Weise Frontend. Das Ökosystem, der Churn und die Akrobatik, den Zustand zwischen Frontend und Backend zu synchronisieren, sind wirklich absurd.
Kürzlich habe ich ein Proof-of-Concept-Projekt mit Go templates und HTMX gestartet und versuche, das Gefühl nachzuahmen, UIs wie in React aus „Komponenten“ zu bauen. Es gibt noch viele raue Kanten, aber Potenzial ist da. Ehrlich gesagt bin ich mir noch nicht sicher, ob HTMX überhaupt nötig ist. Ich habe angefangen, Event Listener selbst zu verwalten, und das scheint mir besser zu gefallen.
Interessanterweise ist komplexes UI-State-Management auf Basis von Benutzerrollen und Berechtigungen auf dem Server viel einfacher. Man schickt einfach nur das HTML, das der Nutzer sehen darf.
Allerdings haben React, Vue usw. enormen Schwung. Ich weiß nicht, wie ein kollektiver Wandel der Denkweise in Gang kommen könnte. Besonders wenn man bedenkt, dass viele Entwickler als Methode zum Bauen von UIs nur Frontend-Frameworks kennen.
Ich bin mir nicht sicher, ob die Aussage stimmt: „Egal welches Framework man wählt, in 5 Jahren ist es obsolete.“
Ich nutze React seit über 10 Jahren professionell.
package.jsondeklariert? Welche node-/npm-Version verwendet das Team?Wenn ihr eine ausreichend aktuelle Version nutzt und populäre Libraries verwendet, habt ihr wahrscheinlich gesehen, wie sich während
npm installDeprecated-Warnungen zu transitiven Abhängigkeiten stapeln.Fairerweise muss man sagen, dass der React-Code selbst die Abwärtskompatibilität ziemlich gut bewahrt hat. Das ist nicht Reacts Schuld. Aber alle Build-Systeme, die man vor 5 Jahren verwendet hat, haben sich geändert und die Abwärtskompatibilität gebrochen. Die Component-Lifecycle-Methoden hatte ich auch schon vergessen.
Selbst ein so gut gepflegtes Projekt wie React kann dem Durcheinander seines Ökosystems nicht entkommen.
Man hat nicht immer die Wahl, aber heutzutage entscheide ich mich meist dafür, reines JS ohne Build-System zu importieren, so viel wie möglich im Python-/Django-Backend zu erledigen und mich komplett aus dem JavaScript-Ökosystem herauszuziehen. Ich habe es nie bereut.
Lässt du deine App immer noch auf React 15?
Kein WYSIWYG-Editor, der unter React 16 läuft, wird noch unterstützt. Wenn eine Sicherheitslücke gefunden wird, ist man in einer „auf Glück hoffen“-Situation. Oder man sollte ihn nicht verwenden.
React 16 wird noch unterstützt, ist aber definitiv obsolete.
Das Gegenargument lautet: Wenn man kein Framework übernimmt, baut man am Ende ein eigenes Framework, das Leute außerhalb des Teams nicht verstehen, meist schlecht dokumentiert ist und an dem man ständig weiterarbeiten muss, um Funktionen hinzuzufügen, die in bestehenden Frameworks bereits vorhanden sind.
Im Frontend gibt es gemeinsame benötigte Funktionen und gemeinsame Probleme, die gelöst werden müssen. Ist es nicht besser, zumindest mit irgendetwas als Grundlage zu starten, statt bei null anzufangen?
Es ist unmöglich, jemanden zu finden, der sofort produktiv sein kann, weil er das interne Framework noch nie gesehen hat. Selbst wenn die Dokumentation sehr gut ist, dauert es, es zu lernen und zu verinnerlichen. Bei langfristigen Einstellungen ist das nicht das Schlimmste, aber wenn man vorübergehend mehr Entwickler braucht, hat man keine Lösung.
Wie ich anderswo schon geschrieben habe: Fast alle wollen eine Webapp oder glauben, sie hätten eine Webapp, aber in Wirklichkeit ist es meistens nur eine dynamische Website. Man muss keinen Framework-Stapel aufbauen, um eine dynamische Website zu erstellen.
Das ist kein Frontend-Problem, sondern ein Problem des JS-Ökosystems. Es passiert auch im Backend.
Die JS-Welt ist ein völliges Chaos aus Abhängigkeiten, die jeweils Dutzende oder Hunderte weiterer Abhängigkeiten haben. Der Abhängigkeitsgraph von Platformatic, einem auf Fastify basierenden Node-Framework, sieht zum Beispiel so aus:
https://npmgraph.js.org/?q=platformatic#zoom=h
Diese Abhängigkeiten können jederzeit aufgegeben werden. Selbst riesige Abhängigkeiten wie Axios oder Express wirkten zeitweise verwaist.
Und jede Abhängigkeit ist der Art ausgeliefert, die der Maintainer für richtig hält. Vor ein paar Tagen hat eine Abhängigkeit, die wir in Production nutzen, entschieden, dass sie die Unterstützung für eine rund drei Jahre alte Safari-Version einstellen kann – obwohl sie etwa 25 Millionen Downloads pro Woche hat, React bei etwa 26 Millionen liegt und sie in 10 Millionen GitHub-Repositories verwendet wird. Wenn man bedenkt, dass Safari in den USA einen mobilen Marktanteil von über 50 % hat, ist das wirklich verrückt.