Wiederholt KI die verlorenen zehn Jahre des Frontends?

• Deskilling ersetzt qualifizierte Arbeit durch technikgestützte Tätigkeiten mit geringerem Qualifikationsniveau, senkt Kosten und Eintrittsbarrieren, schwächt aber auch die Verhandlungsmacht der Beschäftigten
• Im Frontend haben Frameworks und Tools in den vergangenen zehn Jahren Wissen über Browser, Accessibility und Performance verdeckt und die Expertise des front of the frontend verdrängt
• Agentische KI hebt das Programmieren auf eine höhere Abstraktionsebene, ist aber eine nichtdeterministische und bei kleinen Änderungen an Eingaben oder Modellen stark schwankende leaky abstraction
• LLMs sind eine Fortsetzung des Stack-Overflow-Copy-paste: Erfahrene werden schneller, und auch Einsteiger können funktionierende Ergebnisse erzeugen, aber jemand muss die Ausgabe verstehen und korrigieren
• KI kann mehr AI Slop und Kostensenkung erzeugen, beseitigt aber nicht den Bedarf an Menschen, die Qualität, Nutzer und Trade-offs verstehen

---

Frontend und KI-Coding durch die Linse des Deskilling

• Deskilling ist der Prozess, bei dem qualifizierte Arbeit durch Technik ersetzt wird, die von an- oder ungelernten Arbeitskräften bedient werden kann; das senkt Kosten und Eintrittsbarrieren, schwächt aber die Verhandlungsmacht der Beschäftigten
• Die Frontend-Entwicklung hat in den vergangenen zehn Jahren durch JavaScript-Frameworks und Tools ein Deskilling erlebt, und im gesamten Programmieren sorgt agentische KI für eine ähnliche Veränderung
• Wie der Ausdruck Frontend’s Lost Decade andeutet, wurde Frontend-Expertise mit tiefem Verständnis für Browser und Nutzerumgebungen von einer Framework-zentrierten Entwicklung verdrängt

Verschwundene Expertise im Frontend

• Früher erforderte Frontend-Entwicklung Fachwissen zu semantischem HTML, CSS, Browserunterschieden, Accessibility, Progressive Enhancement, Netzwerk-Performance, Interface-Design und Usability-Tests
• Manche Praktiker nennen diesen Bereich zur Abgrenzung vom heutigen „frontend“ front of the frontend
• Das Deskilling im Frontend wurde durch Frameworks und Tools vorangetrieben, die den Browser wie eine einfache Kompilierungszielplattform behandeln, ähnlich einer JVM oder iOS-App-Runtime
• Wer eine Komponente wie Shadcn radio button übernimmt, kann Funktionen bauen, ohne das zugrunde liegende HTML, browserspezifische Feinheiten, Seitenlade-Performance oder Accessibility tief zu verstehen
• Unternehmen können allgemeine Programmierer leichter für Frontend-Aufgaben einsetzen und so Kosten senken
• „Full-Stack-Entwickler“ meint oft nicht mehr jemanden mit tiefem Verständnis für Frontend und Backend, sondern einen Generalisten, der beides mit JavaScript-Frameworks abdecken kann
• Dieselben Entwickler lassen sich leicht zwischen Projekten verschieben, und mit React Native oder Electron sogar für native Apps einsetzen
• Neben dem Vorteil niedrigerer Eintrittsbarrieren wird auch die Verhandlungsmacht der Beschäftigten geschwächt

KI-Coding als höhere und zugleich leaky abstraction

• Die Veränderungen, die derzeit das Programmieren insgesamt erfassen, ähneln denen, die Webentwickler bereits erlebt haben
• Es bewegt sich in Richtung einer Ersetzung qualifizierter Handarbeit am Code durch Technik, die von an- oder ungelernten Arbeitskräften bedient werden kann
• Welche Fähigkeiten Beschäftigte im Umgang mit agentischer KI am Ende brauchen werden und wo Arbeitskosten sowie Kosten für lokale oder Remote-LLMs landen, ist noch unklar
• Klar scheint jedoch, dass Unternehmen diese Technik zur Kostensenkung und zur Schwächung der Verhandlungsmacht von Beschäftigten nutzen könnten
• Dass der Marktwert lange aufgebauter Expertise sinkt, erinnert an den Wandel, bei dem Handwerker und Kunstgewerbler durch Fließbandarbeiter ersetzt wurden
• Deskilling lässt sich auch als Effizienzsteigerung durch Automatisierung verstehen, also als Arbeit auf einer höheren Abstraktionsebene
• Neue Technik verbirgt Details und lässt Bedienende stärker auf das große Ganze schauen, doch was als „nicht wichtig“ gilt, ist eine folgenreiche Entscheidung
• Die Details einer Abstraktion lecken irgendwann immer durch

• Die leaky abstraction des „modernen“ Frontends

  • Abstraktionen gehen oft mit Performance-Kosten einher; für Entwicklerproduktivität etwas Runtime-Performance zu opfern, kann bei leistungsstarken Servern und mittlerer Last vernünftig sein
  • Auf Mobiltelefonen in langsamen Netzen wird derselbe Trade-off zu einem völlig anderen Problem
  • Der Einsatz schwergewichtiger clientseitiger JavaScript-Frameworks wie React und vieler Ökosystem-Pakete abstrahiert Accessibility sowie Performance auf schwachen Smartphones und in langsamen Netzen weg
  • Dadurch werden solche Probleme faktisch zu Dingen, über die man nicht nachdenkt und die man nicht beachtet

• Die Nichtdeterministik agentischen Codings

  • Wenn mit agentischer KI Features gebaut oder Bugs behoben werden, beschreibt man hochrangige Änderungen mit weniger Worten, statt jeden Code selbst zu schreiben
  • Die KI betrachtet Trainingsdaten und Kontext und füllt ausgelassene Details auf; manchmal rät sie richtig, manchmal scheitert sie
  • Ob dieser Ansatz nützlich ist, hängt stark davon ab, was man beim Programmieren für wichtig hält
  • Agentisches Coding ist nicht deterministisch wie ein Compiler; schon kleine Änderungen an Eingaben oder Modellen können zu stark unterschiedlichen Ergebnissen führen, sodass es noch viel stärker leakt als bisherige Programmierabstraktionen
  • Dass KI oft mit einem „Junior Engineer“ verglichen wird, hängt ebenfalls mit dieser Nichtdeterministik zusammen; der Unterschied ist, dass Menschen lernen können, ohne dass man endlos an Dateien wie AGENTS.md oder SKILL.md herumschrauben muss

LLMs als Fortsetzung des Stack-Overflow-Copy-paste

• Die naheliegendste Analogie zur Nutzung von LLMs ist die frühere Nutzung von Google-Suche
• Auch die Fähigkeit, die richtigen Keywords zu wählen, damit passende Forenbeiträge oder Stack-Overflow-Antworten auf der ersten Ergebnisseite landen, war eine erlernbare Entwicklerkompetenz
• LLM-Prompts sind ebenfalls ein Verfahren, das eine passende Kombination aus Trainingsdaten zurückliefert, eher wie eine Abfrage in einem sehr hochdimensionalen Raum als wie eine unscharfe Websuche
• Suchergebnisse reagierten empfindlich auf kleine Formulierungsänderungen und Änderungen im Google-Index, und LLMs reagieren ähnlich empfindlich auf Eingabeform und Modelländerungen
• Google hat die Suche zuletzt so verändert, dass Eingabebegriffe stärker normalisiert werden; dadurch wurde Suchen für Menschen ohne Google-fu leichter, für Erfahrene aber weniger mächtig
• Google und Stack Overflow haben das Programmieren unwiderruflich verändert und ermöglicht, Antworten zu kopieren und einzufügen statt Handbücher zu lesen, wobei überraschend oft etwas herauskommt, das zumindest einigermaßen funktioniert
• LLMs setzen genau diese Entwicklung fort
  • Sie machen Menschen, die wissen, was sie tun, etwas schneller
  • Sie ermöglichen auch Menschen mit wenig Verständnis, etwas zu bauen, das zumindest teilweise funktioniert
• Abstraktionen lecken irgendwann, und dann muss jemand tief verstehen, was tatsächlich passiert, und es reparieren
• So wie man Junior-Entwicklern früher beibrachte, Stack-Overflow-Antworten vor dem Einfügen zu lesen und zu verstehen, sollte man heute LLM-Ausgaben lesen, verstehen und in Bezug auf die bestehende Codebasis einordnen

Der Abstand zwischen Qualität und Geschäftserfolg

• Manche Programmierer gelangten nie an den Punkt, Stack-Overflow-Antworten wirklich zu verstehen, und hielten ein funktionierendes Ergebnis für ausreichend
• Viele Unternehmen waren damit ebenfalls zufrieden, auch wenn sie es nie offen zugegeben hätten
• Heute sind wir an einem Punkt, an dem Unternehmen öffentlich damit werben, wie viel KI sie einsetzen, ohne noch so zu tun, als würden sie die Ergebnisse überhaupt prüfen
• Es gibt klar gültige Einsatzfälle für LLMs, aber ebenso viele neue Wege, Code, Kommunikation und Prozesse in Organisationen zu ruinieren
• Wie beim Code-Review gibt es große Meinungsunterschiede darüber, wie LLMs in Workflows eingesetzt und integriert werden sollten; wenn das nicht zu den Werten eines Teams passt, entstehen erhebliche Probleme im Arbeitsfluss
• Viele Unternehmen funktionieren weiterhin gut, obwohl sie miserable Software bauen
• Anders als Programmierer gern glauben, korrelieren geschäftlicher Erfolg und Softwarequalität nur sehr selten
• Meist wirken andere Faktoren stärker, etwa Marke oder Preis, und Softwareprojekte werden wie Black Boxes behandelt, bei denen Erfolg und Misserfolg ungefähr gleich wahrscheinlich erscheinen
• Auch im Frontend können langsame Websites und viele Cookie-Banner die Conversion verschlechtern, aber ihr Einfluss ist oft geringer als Faktoren wie Markenloyalität oder Preis, und die Websites der Konkurrenz sind häufig ebenfalls langsam
• In einer Atmosphäre nach dem Muster „Noch nie wurde jemand entlassen, weil er React gewählt hat“ werden sichere Entscheidungen gegenüber Qualität bevorzugt
• Das heißt nicht, dass man aufhören sollte, sich um Nutzer und handwerkliche Qualität zu kümmern, aber es ist schwieriger geworden, einen Arbeitsplatz zu finden, an dem das möglich ist
• Wenn die Überhitzung abklingt und klarer wird, wofür LLMs tatsächlich geeignet sind und wofür nicht, könnte ein gewisses Gleichgewicht zurückkehren, aber der Beruf selbst wird nicht mehr derselbe sein

Fähigkeiten, die auch nach der Industrialisierung bleiben

• Als Alltagsprodukte und Gebäude durch industrielle Prozesse massenhaft hergestellt werden konnten, bestand eine Reaktion darin, Fabrikprodukte und Gebäude zu erzeugen, die frühere Stile imitieren und handgefertigt wirken sollten
• Gegen diesen Historismus entwickelte das Bauhaus zu Beginn des 20. Jahrhunderts einen Ansatz, der Fabrikarbeiter und Handwerker nicht gegeneinanderstellte, sondern sie zusammenarbeiten ließ und Kunst und Handwerk unter den Bedingungen industrieller Fertigung neu dachte
• Das Bauhaus verlangte, dass Designer in die Werkstatt zurückkehren und Materialien direkt bearbeiten, das Endziel aber auf massenproduzierbares Design richten
• Software ähnelt dem Handwerk insofern, als geschriebene Programme ohne Fertigungsphase „direkt“ an Nutzer ausgeliefert werden, und dem Industriedesign insofern, als dasselbe Artefakt an Tausende Nutzer verteilt wird
• Die Fähigkeit, Code von Hand zu schreiben, bleibt wichtig; so wie Industriedesigner ihre Materialien kennen müssen, sollten Webdesigner mit HTML und CSS sehr vertraut sein
• Google, Stack Overflow, sofort einsetzbare Bibliotheken und LLMs erleichtern Einsteigern den Start, senken aber zugleich immer weiter die natürliche Hürde, überhaupt etwas zum Laufen zu bringen
• Die Industrialisierung hat viele billige Plastikprodukte hervorgebracht, bei denen Nutzung und Nutzer kaum mitgedacht wurden, aber gutes Industriedesign existiert weiterhin
• Textverarbeitungen haben viele schlecht formatierte Dokumente erzeugt, doch Typografie und Grafikdesign existieren weiterhin
• Wix und Next.js haben viele langsame und wenig zugängliche Websites ermöglicht, aber Praktiker des front of the frontend gibt es weiterhin
• KI ermöglicht viel AI Slop, aber das heißt nicht, dass niemand mehr gebraucht wird, der weiß, was er tut, und dem seine Arbeit wichtig ist

Kommende Veränderungen und Trade-offs

• Wie in anderen Branchen könnte der Anteil wirklich guter Arbeit am Ganzen kleiner werden
• Gleichzeitig wird der Gesamtmarkt weiter wachsen, weil Dinge einfacher und günstiger herzustellen sind
• Ob die absolute Zahl der Menschen, die für gute Arbeit bezahlt werden, steigt oder fällt, ist derzeit schwer zu beurteilen
• Manchmal ist es die richtige Entscheidung, schnell Prototypen oder MVPs herauszuschieben
• Wenn Product-Market-Fit noch nicht gefunden ist, sind schnelle Iteration und Lernen oft wichtiger, als alles von Anfang an zukunftssicher zu bauen
• Man muss allerdings wissen, was man lernen will und wie sich dieses Lernen validieren lässt
• Wenn der richtige Zeitpunkt gekommen ist, ist es meist besser, einen Schritt zurückzugehen und von Anfang an sauber zu bauen
• So ist es zum Beispiel sehr schwierig, später in einem Frontend mit schlechter Architektur noch gute Performance zu erreichen
• Es ist leichter, mit einem einfachen Stack zu beginnen und später Funktionen hinzuzufügen, als umgekehrt
• Mastro wirbt ausdrücklich für gute Performance und einen einfachen Start-Stack
• Ob man Services einkauft, Open-Source-Bibliotheken nutzt, LLM-generierten Code übernimmt oder selbst schreibt: Man muss wissen, welche Trade-offs man in jedem Teil des Systems eingeht
• Wenn sich die Überhitzung legt, wird die Branche erkennen, dass KI nur ein weiteres Werkzeug im Werkzeugkasten ist
• Bis dahin könnten unter dem Banner der KI weiterhin hässlicher Code, kaputte Kommunikation und schreckliche Entlassungen auftauchen

[GN⁺]

Hacker-News-Kommentare

• Ich denke, die von OP vermisste tiefe Fachkenntnis war für viele Menschen in Wirklichkeit ziemlich unerquicklich.
  Ich verstehe schon, dass man davon leben konnte, Browser-spezifische Eigenheiten zu kennen, zugängliche Komponenten selbst zu implementieren und CSS-Spezifität zu beherrschen, aber das meiste davon ist eher zufällige Komplexität. Dass mehr Menschen etwas bauen können, ist eindeutig gut, und wenn ein Teil der Ergebnisse dadurch langsamer ist oder eine schlechtere Barrierefreiheit hat, dann ist das ein wählbarer Kompromiss.
  Man kann sagen, dass Abstraktionen den Nutzern Folgen aufdrängen, die sie nicht gewählt haben, aber ich halte es auch für möglich, dass ein LLM Accessibility-Konventionen besser versteht als ich.

  • Weniger auffällige Aspekte von UX und Softwareentwicklung wie Barrierefreiheit, Intuitivität, Kompatibilität, Reaktionsfähigkeit, Skalierbarkeit, Architektur und Performance sauber zu behandeln, war schon immer schwierig.
    Doch High-Level-Frameworks und inzwischen auch LLMs machen gerade diese Bereiche kaputt und erleichtern es zugleich, halbgarte MVPs schnell auszuliefern; dadurch wird die Lücke zwischen „akzeptabel“ und „gut“ immer größer. Für diejenigen, die auf „gut“ hinarbeiten, wird es zunehmend schwerer, mit denen zu konkurrieren, die „akzeptabel“ durchdrücken.
    Am Ende führt das zu mehr Überstunden und sinkender Softwarequalität, vielleicht sogar zu einem allgemeinen Rückgang der Arbeitszufriedenheit. In letzter Zeit muss ich mit DevTools und uBlock kaputte Websites reparieren oder Störelemente entfernen, nur um grundlegende Funktionen wiederherzustellen, und ich habe hier auch andere gesehen, die dasselbe tun (https://news.ycombinator.com/item?id=47042747). Früher musste man selbst in der Flash-Ära oder in den frühen Browser-Tagen nicht auf diese Weise manuell eingreifen.
    Es gibt auch ein weniger anekdotisches Beispiel: https://news.ycombinator.com/item?id=47390945
    Noch schlimmer ist, dass der Großteil des durch solche Kürzungen eingesparten Geldes nur ganz oben in der Organisation landet.
  • KI macht immer wieder den Fehler, ein animiertes Objekt hinter ein Blur-Objekt zu setzen, wodurch der Browser permanent neu rendern muss.
    So etwas war auch im AI mode von Google enthalten, und andere Websites scheinen ganz offensichtlich per Vibe Coding Ähnliches eingebaut zu haben.
    Anfangs war ich verwirrt, warum die GPU-Auslastung hochschoss und die Lüfter laut drehten, aber inzwischen sehe ich, dass das ein typischer Fehler von KI ist und niemand es ordentlich testet. Menschen können solche Fehler natürlich auch machen, aber bis jetzt ist mir das in meinem ganzen Leben fast nie begegnet.
    Ich nutze einen 240-Hz-Monitor, also wollte der Browser 240-mal pro Sekunde neu rendern, und ich konnte es nur mit uBlock Origin blockieren. Völlig absurd.
  • Texte vom Typ „Wir verlieren unser Handwerk“ haben immer dieselbe depressive Struktur.
    Noch schlechter ist, dass sie ungefähr in der Mitte anfangen, ihre eigene Argumentation zu widerlegen.
    Zum Beispiel heißt es dort, „zu entscheiden, welche Details unwichtig sind, ist eine äußerst bedeutende, manchmal subjektive Entscheidung, und letztlich sickern Details immer durch“. Wenn das so ist, bedeutet das doch, dass auch diese neue Technologie am Ende tiefes technisches Verständnis belohnt. Weil es unvermeidlich ist. Dem stimme ich zu. Aber warum ist dann der Grundton „KI macht meine Fähigkeiten zur billigen Ware“?
    Websites sind technisch gesehen im Großen und Ganzen besser als vor zehn Jahren. Sie haben mehr Funktionen, sind schneller, und SSL/Barrierefreiheit/Responsive Design sind stärkere Defaults geworden. Die Probleme mit Content-Farmen, SEO und Nachrichtenseiten sind eine eigene schreckliche Fehlentwicklung, verursacht durch Werbung und Unternehmensanreize, nicht die Schuld von React.
  • Dass „ein LLM Accessibility-Konventionen besser verstehen wird als ich“, liegt genau genommen daran, dass andere Menschen sie verstanden und aufgeschrieben haben.
    Ein LLM kann das manchmal nutzen. Aber was passiert als Nächstes, wenn Menschen es nicht mehr selbst schreiben?
    Ich stimme zu, dass es gut ist, wenn mehr Menschen Dinge bauen. Wenn alles andere gleich bleibt, gilt: je mehr, desto besser. Wenn sich „KI“ wegen unbestreitbarer Verbesserungen überall durchgesetzt hätte, wären Lage und Stimmung ganz anders.
    Trotzdem haben Menschen keinen selbstverständlichen Anspruch auf durch Arbeit „generiertes“ Wissen. Wenn Zuschreibung und Vergütung ernsthaft behandelt würden und nur mit Material trainiert werden dürfte, für das die Ersteller bezahlt wurden, dann wäre es möglicherweise viel schneller und billiger, einfach CSS zu lernen.
  • Ich halte die Bequemlichkeit, die tiefe Fachkenntnis ignoriert und auf Hacks sowie faule Abstraktionen setzt, für eine Regression, die bis zu den heutigen Frameworks mit mehreren MB und zu Electron führt.
    Natürlich kümmert sich niemand um den Ressourcen- und Speicherverbrauch auf den Rechnern der Nutzer, die verschlechterte Erfahrung, die verschwendete Bandbreite, die zusätzlichen Energiekosten für 8 Milliarden Menschen und die Umweltfolgen.
    Ist es wirklich „eindeutig gut“, wenn mehr Menschen öffentliche Infrastruktur bauen? Wenn das Ergebnis schlechtere Straßen, schlechtere Brücken und ausfallende Systeme sind? Bei Software ist es genauso, und eigentlich gilt das für die meisten Dinge.

• Ein erheblicher Teil der „Frontend-Techniken“, von denen dieser Text behauptet, sie verlören an Relevanz, bestand darin, sich durch ein Minenfeld aus unintuïtiven Ausnahmen, Browser-Inkompatibilitäten, historischer Altlast und Ausnahmen von Ausnahmen von Ausnahmen zu kämpfen.
  Das moderne Frontend, also dieser „Turm leaky abstractions“, kommt endlich einem vernünftigen mentalen Modell für Webentwicklung näher. Es ist zwar gewaltsam auf den Sprengstoffhaufen aufgesetzt, der Webstandards und Konventionen nun einmal sind, aber dass es überhaupt funktioniert und nur ein wenig leakt, ist an sich schon eine Leistung.

  • Die Formulierung „vernünftiges mentales Modell für Webentwicklung“ ist widersprüchlich. Entweder ist es eine Welt voller Minenfeld-Ausnahmen oder ein vernünftiges Modell; beides zugleich geht nicht.
    Wir stecken noch immer in einem Minenfeld von Ausnahmen, und man kann schwer behaupten, dass die Technologien zum Bauen von Frontends inzwischen sauber, vorhersehbar und frei von historischer Altlast wären.
    Alles, was wir getan haben, ist, die Fehler und Inkompatibilitäten im Fundament zu übertünchen, nicht sie zu lösen. React löst nicht die Tatsache, dass HTML nicht als UI-Werkzeugkasten konzipiert wurde. Next.js löst nicht die Designfehler, die verhindern, dass JavaScript zu einer sicheren, vernünftigen und geistig gesunden Sprache wird. Tailwind löst nicht das Problem, dass CSS als Behelf eingeführt wurde, um Markup zu stylen, das nie fürs Styling gedacht war.
    Was LLMs jetzt tun, ist nur, den Horror unter dem Putz statistisch zu „kennen“. Das Modell wurde mit Beispielen aus einer Ära trainiert, in der 99 % der Fälle darin bestanden, die Risse der vorherigen Putzschicht erneut zu stopfen.
  • Ich bin kein Experte, aber wenn man Frontends ausliefert, die die breite Masse sieht, dann ist Frontend wie die gelbe Backsteinstraße aus dem Zauberer von Oz.
    Solange man ein kleines, brauchbares Set bewährter Praktiken nicht verlässt, kann man mit ein paar langweiligen, erprobten Libraries eine ziemlich gute Erfahrung liefern.
    Aber sobald man sich mit dem gerade angesagten Frontend-Framework einlässt, oder schlimmer noch mit dem von gestern, oder sich an die seltsamen Vorlieben anderer Entwickler anpassen muss, die auf genau einer Vorgehensweise beharren, oder anfängt, „geniale“ Hacks zu pflegen, die mit Hoffnung und Gaffer Tape zusammengehalten werden, steigen Komplexität und Interaktionsmuster exponentiell an.
  • Der Originaltext beklagt im Grunde den Verlust eines goldenen Zeitalters, das es nie gegeben hat.
    Ich habe diese Zeit erlebt. Reines JavaScript nur für IE6 wurde durch fehlerhaftes jQuery ersetzt, danach durch unwartbare Angular-Single-Page-Apps und danach durch monströse React-Codebasen.
  • Das wirkt wie eine Aussage, die Unwissen offenlegt.
    In Wirklichkeit ist es noch viel mehr als das.
    Ich habe zu viele Leute in Interviews gesehen, die als Next.js-Experten kamen und sonst nichts konnten. Das ist keine Fähigkeit, sondern nur Wissen — und das liegt heute kostenlos überall herum.
  • Die Fähigkeit zu verstehen, in welchem Turm, auf welcher Etage und in welchem Raum sich diese leaky abstraction befindet, ist weiterhin sehr wertvoll, und LLMs sehen das womöglich nicht.
    Nur weil etwas nicht von Anfang an perfekt von einem Komitee entworfen wurde, heißt das nicht, dass man alles vergessen, das Buch zuschlagen und die Maschine rechnen lassen kann.
    Ich mache Letzteres selbst, also weiß ich, wobei es danebenliegt, aber ich lasse mich deshalb nicht dazu verleiten, unwartbare Chaos-Systeme zu bauen. Jedes Mal, wenn Agenten entgleisen, sind meine Frontend-Fähigkeiten wirklich nützlich.

• Die Aussage „Frontend war eine hochspezialisierte Disziplin, in der man semantisches HTML, CSS, Browser-Unterschiede, Accessibility, Progressive Enhancement, Netzwerk-Performance, Interface-Design, User-Tests und Ähnliches kennen musste“ dürfte für Frontend-Entwickler einer früheren Generation, nämlich C/C++-Entwickler, ziemlich komisch klingen.
  Das Web galt als etwas, das die Einstiegshürde massiv senkte und Fähigkeiten entwertete. Assembler-Programmierer dachten über C/C++-Entwickler wahrscheinlich ähnlich.

  • Jede Schicht hält sich selbst für die wichtigste, spezialisierteste und am stärksten qualifizierte Schicht.
    Aber jede Schicht liegt falsch. Denn jede Schicht baut auf Abstraktionen der darunterliegenden Schicht auf. Wenn man bis zu Physik und Mathematik hinuntergeht, stellt man fest, dass selbst Mengentheoretiker gewisse Axiome voraussetzen. Was Logiker eigentlich tun, weiß niemand.
  • Dieses Zitat stammt gar nicht aus dem Text und hat auch nichts mit ihm zu tun, daher habe ich keine Ahnung, was da eigentlich vor sich geht.

• Die Argumentation nach dem Muster „Es macht mich traurig, dass ein neuer Prozess Ergebnisse geringerer Qualität erzeugt und es vielen egal zu sein scheint“ setzt offenbar voraus, dass diese Arbeit vor KI größtenteils von qualitätsversessenen Meisterhandwerkern erledigt wurde.
  Wer tatsächlich in der Branche gearbeitet hat und ehrlich ist, weiß: So war die Realität nicht. Es gab sehr viel Unterdurchschnittliches.
  Und je nachdem, wie man „Qualität“ definiert, ist es nicht einmal sicher, dass KI-Ergebnisse wirklich schlechter sind. KI kann eine unbequeme Gleichförmigkeit erzeugen, aber gleichzeitig entstehen oft ziemlich brauchbare Resultate, weil die vom Modell gelernten Konventionen — ob man sie mag oder nicht — für die meisten Endnutzer „funktionieren“.

  • Das ist eher wie „noch einen Ziegel auf die Mauer setzen“.
    Schon vorher gab es viel Druck, nur das absolute Minimum zur Erfüllung der Anforderungen zu liefern und das dann als Erfolg zu deklarieren. Jetzt fühlt sich dieser Druck schlicht untragbar an.
  • Zur Annahme, dass vor KI qualitätsbewusste Meisterhandwerker am Werk waren: Manche Leute haben im Lauf ihrer Karriere tatsächlich ein paar Mal das Glück gehabt, solche Phasen zu erleben.
    Ich stimme aber zu, dass das schon vor KI verschwunden war.
  • Der Qualitätsmaßstab scheint erschreckend niedrig zu sein.
  • Stimmt. Das Web vor jQuery und Bootstrap war chaotisch und hat auch beim Coden keinen Spaß gemacht.
    Wenn wir von niedriger Qualität sprechen, war das damals eher der Normalzustand.

• Kürzlich hatte ich selbst einen ähnlichen Gedanken.
  Ich habe seit mindestens 10 Jahren kaum noch Frontend-Entwicklung gemacht, bin aber alt genug, um mich an die Zeit Ende der 2000er zu erinnern, als plötzlich alle anfingen, Web-GUIs nicht mehr von Hand zu bauen, sondern Frameworks zu verwenden, und Leute, die weiterhin HTML/CSS/JS und Datenbankabfragen von Hand schrieben, verspottet wurden. Auch Stellenanzeigen verlangten plötzlich nicht mehr PHP/HTML/CSS/SQL/JS, sondern Ruby on Rails, Django, Spring, GWT und später Angular.
  Das fühlt sich heute auf seltsame Weise vertraut an. Man konnte ohne tiefes Wissen in wenigen Minuten funktionierende Webanwendungen bauen, und das wirkte wie Magie. Danach überflog man grob die Dokumentation und passte Dinge innerhalb des Frameworks mit Suchen und Herumprobieren an, bis man irgendwann nicht mehr weiterkam. Weil man überhaupt nicht verstand, wie das Innere funktionierte. Wie bei Vibe-Coding-Webapps waren die am Nachmittag zusammengeklebten Standard-Framework-Webapps schon aus der Ferne zu erkennen, aber auf Manager machten sie großen Eindruck.
  Interessant ist, dass Entwickler über ihr bevorzugtes Frontier-Modell ähnlich sprechen wie GUI-Entwickler vor 15 bis 20 Jahren über ihre geliebten Web-Frameworks. Sie vermenschlichen das Werkzeug und identifizieren sich sogar damit, verzweifeln daran, dass etwas in Version X ging und in X.1 schlechter wurde, und wiederholen Sätze wie „Jetzt entwickle ich 10-mal schneller“ oder „Ich schreibe XYZ wieder von Hand“.

  • Andererseits war die spätere Nutzung von Frameworks auch ein guter Versuch der Standardisierung.
    Eine selbstgebaute GUI, die niemand bedienen oder pflegen kann, ist auch kein Vorteil.
    Persönlich lehne ich Dinge ab, die sich wie Nuxt/Next zu groß „anfühlen“, aber Vue mag ich. Im Moment möchte ich JavaScript jedoch größtenteils loswerden und eher zu HTMX oder Alpine-artigen Lösungen mit serverseitigen Templates gehen.
    Für mich gilt: Je weniger Technologien im Einsatz sind, desto besser. Es gab ja auch Zeiten, in denen Webapps schon mit jeder Menge nutzlosem Ballast gefüllt waren, bevor man überhaupt eine Zeile Custom Code hinzufügte.
  • Schon Anfang der 2000er waren Webentwickler es leid, alles von Hand zu programmieren, und suchten nach Automatisierung wie Frameworks oder CMS.
    Ich habe 2004 auch einmal eine Website mit einem sehr einfachen Ansatz gebaut: txt-Dateien in einem Verzeichnisbaum, die dann per PHP in HTML eingefügt wurden, wobei statt Zeilenumbrüchen Tags gesetzt wurden. Die Alternative damals waren schwere Content-Management-Systeme.
    Nachdem ich bei der Arbeit durch zwei furchtbare PHP-Frameworks musste, die Lead-Entwickler gebaut hatten, kam ich zu Django; daher war ein Framework wie Django eher ein schrittweiser Übergang und deutlich angenehmer.
    Natürlich wurde es sehr heikel, wenn man noch weiterging und etwa Versionsverwaltung zu Objekten hinzufügte; dann war nichts mehr garantiert funktionsfähig und es gab auch keinen klaren Weg, es zu reparieren.
    Trotzdem scheint die Grundhaltung der heutigen ziemlich ähnlich zu sein.

• Wir sind in der Softwarebranche. Der Kern dieser Branche ist es, hochgradig repetitive Arbeit zu automatisieren.
  Frontend-Projekte sind sehr repetitiv, und jetzt übernimmt AI das. Das ist großartig und schafft viel Zeit, um interessantere Dinge zu bauen.
  Dass weniger relevante Fähigkeiten dequalifiziert werden, passiert in dieser Branche seit der Erfindung des Computers ständig. Denn wir haben das Problem entweder mit AI oder auf andere Weise gelöst.
  Man muss weiterziehen und neue Technologien lernen. Tatsächlich ist auch der effektive Einsatz von AI eine Fähigkeit, mit der manche Menschen Schwierigkeiten haben. Dinge entstehen noch immer nicht einfach von selbst. Mit den richtigen Prompts kann man vieles schaffen, aber gibst du wirklich die richtigen Prompts? Tut das Werkzeug tatsächlich, worum du gebeten hast? Woher weißt du das? Hast du es überprüft? Ich verbringe selbst enorm viel Zeit damit, AI zu prompten, werde eindeutig besser darin, aber es ist immer noch fast ein Vollzeitjob.
  In etwa zehn Jahren werden wir wohl zurückblicken und sagen, dass auch diese Methode eine sehr ineffiziente Art war, Software zu bauen. Die Werkzeuge werden besser, und AI wird autonomer werden. Wenn du den ganzen Tag damit verbringst, dieselben Prompts zu wiederholen, dann muss das irgendwann auch von jemandem oder etwas automatisiert werden.

  • Der Zweck von Software besteht darin, menschlichen Willen in einen Zustand zu kodieren, den Maschinen kommunizieren können.
    Die Beschwerde hier ist, dass diese Automatisierung Gefahr läuft, etwas Unerwünschtes zu kodieren.
  • Statt das Frontend aufzugeben, sollte die neue Effizienz durch AI Ressourcen freisetzen, um Frontend und Backend weiter voranzutreiben.
    Die Welt braucht weit mehr Software, als wir derzeit bauen können.
  • Ich habe keine Ahnung, was mit „Frontend-Projekte sind sehr repetitiv“ überhaupt gemeint ist.
    Das ist so eine miserable Sichtweise, dass ich gar nicht weiß, wo ich mit dem Widerspruch anfangen soll. Ist gemeint, dass in jeder UI Buttons vorkommen und das deshalb repetitiv sei?
    Wenn Leute das wirklich glauben, verstehe ich, warum UX seit den 90ern kaputt ist und seitdem nur noch schlechter geworden ist.
  • Es würde dich vielleicht überraschen, wie wenige „interessante Dinge“ es tatsächlich zu bauen gibt.

• AI-Coding ist eine große Hilfe beim Erstellen von Produktprototypen, bringt aber zugleich Produkte hervor, denen man schon aus der Ferne ansieht, dass sie von AI gemacht wurden.
  Gerade eben hat ein Startup eine App vorgeführt, und sie hatte genau diesen Vibe-Coding-UI-Look.
  Das Feedback, das sie bekamen, war kühl, aber treffend: „Ganz ordentlich, aber man sieht zu deutlich, dass es mit AI gebaut wurde. Und wenn das so ist, kann jeder andere, der so etwas will, es ebenfalls sehr schnell mit AI bauen, also steckt in dem, was ihr verkaufen wollt, nicht viel Wert.“

  • Davon hätte ich gern mehr. Sowohl von UIs, die von LLMs erzeugt wurden, als auch von Menschen, die das für ausreichend halten, bekomme ich kaum noch Luft.
  • Interessant ist, dass schon ein grundlegendes Designsystem und etwas CSS dafür sorgen, dass von AI generierter Frontend-Code ziemlich natürlich zusammenpasst.
    Aber die meisten investieren nicht einmal so viel grundlegende Sorgfalt.
    Abgerundete Ecken sind weiterhin ein endloser Trend, und alles, was nicht bereits gut definiert ist, scheint von dieser Form angesteckt zu werden.
  • Das klingt eher nach einer Fantasie im Kopf als nach etwas, das tatsächlich passiert ist.
    Ein kompetenter Venture-Capital-Investor würde so bedeutungsloses Feedback nicht geben. Wenn es gut ist, ist es gut — was spielt es dann für eine Rolle, ob es mit AI gemacht wurde? Wäre ein Produkt gleicher Qualität also akzeptabel gewesen, wenn es nicht nach Vibe Coding ausgesehen hätte? Das ist nur für Leute ein Thema, die AI ideologisch ablehnen.

• Manchmal habe ich das Gefühl, dass die Techniken aus den frühen 2000ern, mit denen man komplexe Benutzeroberflächen in HTML ohne AJAX oder DOM-Manipulation gebaut hat, praktisch verschwunden sind wie der Bau der Pyramiden
  Junge Full-Stack-Entwickler sind teilweise „dequalifiziert“, sodass viele zum Beispiel denken, man brauche für Formularvalidierung JavaScript
  Sobald man anfängt, AJAX zu verwenden und das DOM zu manipulieren, führt die Komplexität asynchroner Kommunikation zwangsläufig zu etwas in einer ähnlichen Größenordnung wie React. Auch wenn man einfach document.title="A new title" schreiben kann und nichts extra dazuholen muss, reicht es schon, Frontend als „UI aktualisieren, wenn Daten vom Server kommen“ zu betrachten: Komplexe Anwendungen müssen mehrere Teile der UI aktualisieren, und irgendwann baut man so etwas wie Kommunikation oder einen State-Management-Bus. Ob man es anders hätte bauen können? Natürlich
  Wenn es ein Problem im React-Ökosystem gibt, dann nicht, dass es eine Abstraktion schafft, auf der weitere Abstraktionen aufbauen, sondern dass diese Abstraktion leckt. Wenn man etwas sehr Einfaches baut und sich nicht um das Aussehen kümmert, kann man Bootstrap oder MUI nutzen, ohne CSS zu verstehen. Aber wenn man professionelle Arbeit liefern will, die man Kunden zeigen kann, muss man HTML, CSS, JS und alle im Projekt verwendeten Frameworks verstehen

  • Besonders auf HN habe ich oft das Gefühl, dass React wie ein vierbuchstabiges Schimpfwort verwendet wird, das für eine breitere Unzufriedenheit mit interaktiven Webanwendungen insgesamt steht
    Die meisten, die React kritisieren, verstehen nicht wirklich, welches Problem React löst. Wenn man ihnen den Source Code einer ausreichend komplexen Webapp zeigt, die nicht auf React setzt, kann man darin ein selbst gebautes React-ähnliches Konstrukt finden

• Ich stimme nicht zu, dass der Betrieb einer Frontend-Anwendung mit Server-Side Rendering, Lazy Loading usw. in NextJS „einfacher“ ist als früher, als man nur HTML, JS und CSS verwendet hat
  Das Niveau der Komplexität und die Erwartungen der Nutzer liegen heute an einem völlig anderen Punkt
  Außerdem gibt es etwa 1000-mal mehr qualifizierte Ingenieure, und man muss mit dem Weltmarkt konkurrieren. In den frühen 2000ern gab es fast keine Konkurrenz. Die Fähigkeiten von Arbeitskräften korrelieren meist nur lose mit dem Niveau, das der Markt verlangt, aber heute ist alles extrem wettbewerbsintensiv