Übermäßig JavaScript-zentrierte Entwicklung ruiniert das Web
(jonoalderson.com)Zusammenfassung
Übermäßig JavaScript-zentrierte Entwicklung ruiniert das Web
- Der Missbrauch von JS-Frameworks verschärft die Komplexität von Websites
- Developer Experience (DX) überlagert die User Experience (UX)
- Selbst einfache Aufgaben erfordern übermäßige Strukturen
- Performance, Barrierefreiheit und Wartbarkeit verschlechtern sich gleichermaßen
- Die Lösung liegt in der Rückkehr zu den eigentlichen Funktionen des Webs
Einleitung
Die Missstände eines entwicklerzentrierten Webs
- Die meisten Websites sind übermäßig komplex und langsam
- Durch JS-zentriertes Design hat sich die Struktur von nutzerorientiert zu entwicklerorientiert verschoben
- Selbst einfache Änderungen erfordern inzwischen häufig komplexe Deployment-Prozesse
Hauptteil
Der Wunsch, wie eine App auszusehen, ist die Ursache
- Seit den 2010er-Jahren stieg mit dem Boom mobiler Apps auch die Nachfrage nach einem „Web wie eine App“
- Mit der Einführung von JS-Frameworks wie Angular nahm die Komplexität stark zu
- Selbst einfache Inhalte werden wie ein System entwickelt
Eine Kultur, die Developer Experience (DX) priorisiert
- Moderne Frameworks konzentrieren sich auf die Bequemlichkeit von Entwicklerinnen und Entwicklern
- Die Abstraktion von Komponenten führt zu einer Entkopplung von der UX
- Noch vor der Frage „Warum nutzt man React für einen Blog?“ wird über SSR-Kompatibilität diskutiert
Eine Realität, in der Komplexität zum Standard geworden ist
- Selbst für einfache Aufgaben sind mehrstufige Strukturen mit Build, Routing, API und Cache nötig
- Durch komplexe Stacks können Nicht-Entwickler Inhalte nicht mehr selbst bearbeiten
- Der technologische Wandel ist so schnell, dass Wartung schwierig wird
Die Schäden durch den Missbrauch von Frameworks
- SSR, Cache, Metadaten und andere bestehende Web-Funktionen werden erneut implementiert
- Die Performance ist schwächer, während die Abhängigkeiten zunehmen
- Am Ende entsteht der Widerspruch, ein CMS mit JS-Frameworks nachzubauen
Sinnlose Wiederholungen und Kosten
- Einführung und Abschaffung von Frameworks wiederholen sich, wodurch eine stabile Struktur ausbleibt
- Statt echte Nutzerprobleme zu lösen, konzentriert man sich auf die Bewältigung interner Komplexität
- Content-Marketing, SEO und Experimente verzögern sich, während sich die User Experience verschlechtert
Schäden für Nutzer und Marketer durch JS-Missbrauch
- Für Änderungen an Inhalten ist die Beteiligung von Entwicklern nötig
- SEO und Seitenqualität leiden
- Für Nutzer nehmen Probleme wie Ladeverzögerungen und Interaktionsfehler zu
JS ist nur ein Werkzeug, nicht das Ziel
- JS ist ein mächtiges Werkzeug, für die meisten Websites jedoch überdimensioniert
- Für statische Inhalte reichen HTML, CSS und etwas JS völlig aus
- Vanilla JS, Server-Side Rendering und minimale Skripte sind effizienter
Konzentration von Befugnissen und strukturelle Probleme
- Durch komplexe Stacks hängt jede Arbeit von Entwicklern ab
- Organisatorisch konzentriert sich Macht auf Entwicklerinnen und Entwickler
- Technische Entscheidungen werden eher nach Entwicklerkomfort als nach Nutzerbedürfnissen getroffen
Fazit
Die Wiederherstellung des Wesens des Webs ist die Lösung
- Es braucht Websites, die schnell laden, auffindbar sind und sich leicht warten lassen
- Die Rückkehr zu Grundlagen wie serverseitig gerendertem HTML, semantischem Markup und minimalem JS ist der richtige Weg
- Es braucht einen ergebnisorientierten Ansatz statt eines technologiezentrierten
- Die Frage „Warum verwenden wir diese Technologie?“ muss gestellt werden
- Ein einfaches und nutzerzentriertes Web bringt Performance, niedrigere Kosten und Flexibilität
23 Kommentare
Wenn man sich nur WordPress anschaut … dann scheint das wohl die Antwort auf das obige Problem zu sein. WordPress hat auch einen viel höheren Marktanteil, obwohl es langsam ist …
Ich denke, wenn es als Beleg Benchmark-Ergebnisse gäbe, könnten Entwickler dem eher zustimmen. Bei übermäßigem Framework-Coding wird eine Website zwar sicherlich langsamer, aber ich habe persönlich häufiger gesehen, dass bei Seitenwechseln innerhalb der Website mit Vanilla-Code erstellte Seiten langsamer sind als optimierte Framework-Seiten. Wenn es sich natürlich um eine Website handelt, die nur aus statischen Daten besteht, ist eine reine HTML-+CSS-Lösung vielleicht schneller, aber ich bin mir nicht sicher, wie häufig Websites heute sind, die nur aus statischen Daten bestehen.
Wenn es so etwas wie React oder Vue nicht gäbe,
müsste man selbst bei gleicher Funktionalität den Code deutlich komplexer umsetzen, oder?
Gerade beim Umgang mit Pop-ups wird schon das bloße Weiterreichen einer einzigen Prop in reinem JavaScript ziemlich kompliziert.
Wenn schon bei so einfachen Dingen der Code komplex wird, dann wird es bei wirklich
komplexen Funktionen schwer, sie überhaupt zu implementieren.
Das ist zwangsläufige Komplexität. Es ist nicht mehr wie früher einfaches Template-HTML.
Es gibt doch gar nicht so viele Browser, die die Leute verwenden, aber warum gibt es dann so viele Frameworks? Wäre es nicht am besten, wenn die Unternehmen, die die Browser betreiben, ein optimales Framework entwickeln und es gemeinsam mitverwalten würden? Wie lange soll dieser Teufelskreis noch weitergehen?
Die angestrebten Entwicklungsphilosophien unterscheiden sich eben stark voneinander.........
Dem beschriebenen Phänomen stimme ich zu, der Schlussfolgerung aber nicht.
Die vordergründige Ursache des Phänomens ist, wie auch im Artikel erwähnt, die gestiegene Nachfrage nach einem „app-ähnlichen Web“.
Sowohl damals als auch heute war das Web eigentlich nicht besonders geeignet, um „etwas App-Ähnliches“ zu bauen, aber mit genug Verrenkungen ist es in einem Zustand, in dem man „etwas Ähnliches bauen kann“.
Tatsächlich wurde das Web seinem Ursprung nach als Plattform geschaffen, um eine Art „Dokumente“ wie wissenschaftliche Arbeiten zu teilen.
Das erkennt man schon an den grundlegenden Bausteinen von HTML.
Dann kamen Technologien auf, mit denen sich dynamische Inhalte erzeugen ließen, etwa CGI, und als auf Browser-Seite Skriptsprachen eingebaut wurden, konnte man den Ergebnissen Dynamik verleihen. Damit begann die Ablösung vom „Web als Dokument“.
Das Problem ist, dass das Fundament des Webs vom ersten Moment dieser Ablösung bis heute weiterhin ein auf „Dokumenten“ basierendes System ist.
Natürlich sind mit WebSocket, WebRTC, WASM und ähnlichem viele neue Technologien entstanden, die sich von der „Dokument“-Ausrichtung entfernen, aber bis heute werden die meisten Websites weiterhin auf Grundlage der bestehenden „dokumentbasierten“ Plattform entwickelt.
Noch immer müssen wir
div-Tags aufeinanderstapeln, um Bildschirme zu zeichnen.Bis hierhin wäre das die Analyse des Phänomens, und dann fragt man sich natürlich, was die Antwort darauf ist.
Wenn man die Realisierbarkeit völlig außer Acht lässt und sich die Funktionen einer idealen nächsten Plattform vorstellt, sähe das so aus:
(Nicht, dass alle Websites so sein müssten, sondern nur Seiten mit Anwendungscharakter.)
Der Browser würde zunächst eine Art App-Launcher werden.
Wenn man eine Anwendung einmal heruntergeladen hat, sollte sie auch offline ausführbar sein.
Und die Apps würden nicht mehr mit dem bisherigen HTML/CSS/JS umgesetzt, sondern in anderen Sprachen.
Dabei könnte der Browser, ähnlich wie Android, eine Art Framework bereitstellen.
Auch die Kommunikation mit dem Server könnte sich vom bisherigen Web-Request-Modell lösen und ein anderes Paradigma verwenden.
Für Kommunikation mit Echtzeit-Anforderungen könnte man weiterhin das bestehende TCP direkt nutzen,
oder man könnte eine neue, einfachere RPC-Kommunikation schaffen und verwenden, die nicht auf dem HTTP-Protokoll basiert.
Ich bin mir nicht ganz sicher, was Sie mit dem letzten Punkt meinen, den Sie als idealistische Plattform bezeichnet haben.
Letztlich geht es doch um die Zeit, als man native Programme herunterladen und dort ActiveX verwenden musste.
Im Kern ist das Problem gewissermaßen ein Verrenkungsakt, um innerhalb des auf Web-„Dokumenten“ basierenden HTTP-Protokolls ein app-ähnliches Web zu bauen.
Die Meinung war daher: Wenn man dafür Funktionen auf App-Ebene braucht, warum nicht ein neues Protokoll und Framework speziell für Apps schaffen?
So wie auf Smartphones keine reinen nativen Programme laufen, sondern gewissermaßen sandboxed Apps, wäre das dann eine Struktur, die auf Browser-Ebene ausgeführt wird.
Natürlich müssten Offenheit und Standardisierung dem vorausgehen, damit es nicht in Richtung ActiveX abgleitet.
Auch wenn es sich um ein app-ähnliches Web handelt, denke ich, dass man sich zumindest in die Richtung des im Fazit Genannten bewegen sollte. Wenn man viel JavaScript verwendet, wird es aus Sicht des Clients schwergewichtig.
Tatsächlich fehlt es nicht einmal an Frameworks, mit denen sich das so umsetzen lässt. Schon bei Next.js ist das grob möglich, wenn man den Einsatz von Client Components auf das Notwendige minimiert. Und im Rails-Umfeld, das jemand anderes erwähnt hat, gibt es mit Hotwire (https://hotwired.dev/) ein Framework-Set für app-ähnliche Webanwendungen (Turbo, Stimulus usw.), mit dem man dem vom Autor genannten Fazit sehr nahekommen kann.
Ich kann die grundlegende Problemwahrnehmung dieses Artikels nachvollziehen, aber an manchen Stellen bringt er mich doch etwas zum Stirnrunzeln.
Zum Beispiel bewahrt die Werbe-Website für einen bestimmten Dienst, den unser Unternehmen betreibt, genau die Art von Einfachheit, die dieser Artikel lobt. Glücklicherweise sind die meisten Elemente dieser Website hinreichend statisch. Der Frontend-Code wie HTML und CSS wurde von Menschen direkt von Hand geschrieben, ganz ohne Framework, und bei JS hängen nur jQuery und Google Analytics dran. Dinge wie Bekanntmachungen oder ein schwarzes Brett sind zwar per AJAX mit jQuery umgesetzt, aber ich halte das weder für unvernünftig noch für übermäßig komplex. Meiner Meinung nach ist das ungefähr auf dem Niveau, das ich umsetzen konnte, als ich vor langer Zeit mit grundlegender Webentwicklung anfing. Soweit ich weiß, wird diese Seite noch seit der Zeit des Internet Explorer betrieben, also habe ich sie nicht selbst gebaut, aber ich finde sie gar nicht schlecht.
Allerdings gibt es hier Git-Versionsverwaltung und eine CI/CD-Pipeline, und Staging-Server und Produktionsserver sind voneinander getrennt. Wenn ein Pull Request in den Main-Branch gemergt wird, deployt die Pipeline das vom Bundler erzeugte Artefakt automatisch auf den Staging-Server, und nachdem die zuständige Person den Staging-Server geprüft und die endgültige Freigabe erteilt hat, wird es anschließend auf den Produktionsserver ausgerollt. Früher wurden die Quelldateien einfach per FTP direkt auf dem Produktionsserver überschrieben, aber nachdem die entsprechende Arbeit an unser Team überging, haben wir das so geändert.
Ist das wirklich unvernünftige Komplexität? Früher war das Ändern des Title-Tags dieser Website eine Sache von: mit AcroEdit auf den Produktionsserver per FTP verbinden (ja, die Leute, die das HTML dieser Seite ursprünglich direkt geschrieben haben, benutzten das immer noch), eine Zeile in der HTML-Datei direkt ändern und speichern, und damit war alles erledigt. Daher könnten sie das wahrscheinlich tatsächlich so empfinden.
Ich denke jedoch, dass dieses Maß an zusätzlicher Komplexität absolut vertretbar war. Nicht jede Aufgabe ist schließlich so einfach wie das Ändern eines einzigen Title-Tags. Und dass alter, nur auskommentierter Code, der überall angeklebt war, jederzeit wiederhergestellt werden kann, erlaubt es einem, ihn ohne große Last vollständig zu löschen; außerdem sind transparente Nachverfolgung von Änderungen und Rollbacks möglich, und der Bundler kann bei Bedarf noch einige grundlegendere Optimierungen hinzufügen. Das sind meiner Ansicht nach klare Vorteile. Auch das Hinzufügen eines Staging-Servers, auf dem man vor dem Deployment in die reale Umgebung eine Vorschau sehen kann, könnte man als eine Form von Komplexität ansehen, aber ich halte das für notwendig.
Auch ich habe viele Beschwerden darüber, dass die internen Code-Strukturen verschiedenster Websites übermäßig komplex und schwerfällig geworden sind. Die Outlook-App unter Windows basiert heutzutage auf einer Web-App, und in letzter Zeit ist sie besonders noch schwerfälliger geworden. Es ist inzwischen so weit, dass es schon ruckelt, wenn man einfach nur den Mail-Text auf dem Bildschirm schreibt oder den gesamten Text markiert, und im Extremfall erscheint sogar "Seite reagiert nicht". Als ich mich fragte, warum das so ist, und in Web-Outlook die Entwicklertools öffnete, war ich ehrlich schockiert. Nachdem ich einmal den Cache geleert und die Seite neu geladen hatte, liefen selbst eine Minute später noch immer irgendwelche Requests weiter. Als ich im Browser nachsah, waren allein im Zusammenhang mit der MS-Office-Site mehrere Gigabyte an Daten gespeichert.
Dieser Artikel wirft jedoch vieles durcheinander; manchen Punkten stimme ich zu, manchen eher nicht. Was semantisches HTML oder Barrierefreiheit betrifft, war die Vergangenheit meinem Wissen nach sogar noch viel schlimmer. Und dass eine Verbesserung der Developer Experience die User Experience verschlechtere, kann ich überhaupt nicht nachvollziehen — vielleicht liegt das daran, dass ich kein Web-Frontend-Entwickler bin. Sogar die Behauptung, dass sich alle Macht und Kontrolle bei den Entwicklern konzentriert hätten, klingt für mich absurd. Liegt die Macht in Unternehmen nicht beim Management? Oder sind Unternehmensstrukturen im Westen vielleicht doch etwas anders als in Korea?
Wie immer stimme ich voll und ganz zu, dass Ausgewogenheit und Maß, Einfachheit und Pragmatismus wichtige Werte sind und bei Entscheidungen priorisiert werden sollten. Aber dieser Artikel argumentiert so, als sei "alle Websites wie Softwareprodukte zu behandeln" vollständig die Verantwortung der Entwickler, und ich denke, genau das verwässert eher die grundlegende Problemwahrnehmung. Und die Stellen, die die "gute alte Zeit" verklären, in der es keine gewachsenen Prozesse gab, verdienen meiner Meinung nach eher Kritik.
Ist das nicht eine völlig andere Geschichte als das, worüber Sie sprechen?
An welcher Stelle halten Sie das für eine völlig andere Geschichte?
Letztlich wird in diesem Artikel meiner Meinung nach übermäßige Komplexität und die dadurch entstehende Aufblähung kritisiert. Nur weil ich in meinem Kommentar JavaScript nicht erwähnt habe, halte ich ihn nicht für völlig themenfremd. In gewisser Weise ist es schließlich eine Kritik an eher nebensächlichen Aspekten. Und wie ich in meinem Kommentar von Anfang an erwähnt habe, teile ich auch die grundlegende Problemwahrnehmung des ursprünglichen Artikels.
Ich glaube, Sie haben die Absicht des Originaltexts missverstanden.
„...hier sind Git-Versionsverwaltung und eine CI/CD-Pipeline angebunden, außerdem sind Staging-Server und produktiver Server voneinander getrennt. Wenn ein Pull Request in den Main-Branch gemergt wird, wird das vom Bundler erzeugte Ergebnis in der Pipeline automatisch auf den Staging-Server deployt. Nachdem die zuständige Person den Staging-Server geprüft und die Freigabe für das Deployment final erteilt hat, wird es anschließend erneut auf den produktiven Server deployt. Früher wurden die Quelldateien einfach per FTP direkt auf dem produktiven Server überschrieben, aber nachdem die entsprechenden Aufgaben an unser Team übergegangen sind, haben wir das so geändert.
Ist das wirklich irrational komplex?“
Das haben Sie geschrieben, aber ich glaube, das hat mit dem Text nicht viel zu tun. Der Aufwand, Deployment und Verwaltung auf diese Weise zu organisieren, und das, was dieser Artikel behauptet, sind meiner Meinung nach ziemlich unterschiedliche Dinge.
Die Absicht des Originaltexts besteht nicht einfach darin, nur die komplexer gewordenen JS-Frameworks zu kritisieren.
Der Einfachheit halber zitiere ich aus dem oben verlinkten koreanischen Übersetzungstext.
Im Unterschied zu Korea, wo die Entwicklungskultur von der Führungsebene über Planer bis zu den Entwicklern nach unten weitergegeben wird, gibt es im Westen kein Konzept, das dem koreanischen Planer entspricht, und Entwickler sind dort teilweise aktiv an der Produktplanung beteiligt. Auch westliche PMs entsprechen den koreanischen Planern nicht vollständig, so wie ein Cover Letter und ein Selbstvorstellungsschreiben keine völlig deckungsgleichen Konzepte sind. Natürlich gibt es auch bei Spielen, die stark von kreativen Projekten geprägt sind und bei denen Spaß und Gameplay wichtig sind, im Westen im Vergleich zu Asien flachere Hierarchien, aber auch dort verläuft die Entscheidungsweitergabe vom Director zu den Entwicklern.
Es gibt also einen solchen Unterschied.
Aber ich denke, das steht nicht in einem besonders großen Zusammenhang mit dem oben Gesagten.
Nutzt Rails, seid glücklich
Ich stimme der Kernaussage dieses Artikels zu. Heutzutage wird JavaScript viel zu exzessiv eingesetzt, sodass Websites oft ruckeln, selbst wenn man einen i9-9900k verwendet. Als Gaming- oder Arbeitsrechner sind die Spezifikationen zwar etwas unklar einzuordnen, aber in der Realität gibt es unzählige Bürocomputer mit noch schwächerer Ausstattung.
Deshalb mag ich Frameworks wie Astro und Hotwired, deren Philosophie darin besteht, JS nur dann zu verwenden, wenn es wirklich nötig ist, etwa für interaktive Bereiche oder interaktive Seitennavigation. Ich mag auch Server-Side Rendering, also den Ansatz, auf der Serverseite zu rendern. Dagegen kann ich CSR (einschließlich Fällen, in denen nur die Meta-Tags serverseitig gerendert und der Rest per CSR verarbeitet wird) überhaupt nicht leiden. Denn ich sehe darin, dass Aufgaben, die der Server übernehmen sollte, auf den Client abgewälzt werden. Meiner persönlichen Meinung nach sollte der traditionelle SPA-Ansatz mit CSR nur dann genutzt werden, wenn das Frontend lokal in einer App wie Electron ausgeführt wird. Wenn das Frontend jedoch vom Server geladen wird, sollte man natürlich SSR verwenden.
Im Folgenden eine Zusammenfassung der Kommentarreaktionen zum Beitrag, eingeteilt in 5 Typen:
1. Volle Zustimmung und Unterstützung
Hauptmerkmale: Die Argumentation des Artikels wird voll unterstützt, und die Probleme komplexer JS-Stacks werden anerkannt.
Beispielmeinungen:
2. Sorge über den Missbrauch von Frameworks
Hauptmerkmale: Kritisiert wird der übermäßige Einsatz von Frameworks wie React und Angular; die Meinung ist, dass einfache Technologien ausreichen.
Beispielmeinungen:
3. Teilweise Zustimmung + Berücksichtigung der Realität
Hauptmerkmale: Es gibt Zustimmung zur Kernaussage, zugleich aber auch die realistische Sicht, dass Komplexität teils unvermeidbar oder notwendig ist.
Beispielmeinungen:
4. Kritik an Entwicklungskultur und Branchenstruktur
Hauptmerkmale: Es wird darauf hingewiesen, dass der Framework-Überschuss nicht nur ein technisches Problem ist, sondern ein Produkt von Einstellungspraktiken, Kultur und Marketingstrukturen.
Beispielmeinungen:
5. Kritik oder Widerspruch
Hauptmerkmale: Es besteht keine Zustimmung zu den Grundannahmen des Artikels, oder er wird als einseitig kritisiert.
Beispielmeinungen:
Oh, nach Typen aufgeteilt ist es übersichtlich und gefällt mir gut.
Ich stimme dem im Originaltext angesprochenen Problem der „übermäßigen Komplexität des Webs“ zu. Aber ich halte es für schwierig, die Ursache allein auf Entwicklerkultur oder den Missbrauch von Frameworks zurückzuführen. Die Komplexität des heutigen Webs ist zu einem erheblichen Teil der Schatten unvermeidlicher Funktionen und Sicherheitsanforderungen, die das „Geschäftsmodell“ verlangt. Lässt man diesen Punkt weg, bleibt die Diagnose zwangsläufig unvollständig.
Das Web ist längst keine „kostenlose Ausstellungshalle“ mehr. Die meisten Web-Services von heute – mit Ausnahme öffentlicher Websites – haben das Ziel, Umsatz zu generieren. Deshalb sollte die zentrale Frage bei der Technologiewahl nicht lauten: „Ist dieser Code rein?“, sondern: „Hilft diese Technologie unserem Business, erfolgreich zu sein?“
Aus dieser Perspektive stößt das vom Originaltext idealisierte „leichte Content-Web“ an die Wand realer Business-Anforderungen. Ein Business, das etwa Inhalte verkauft, kann mit einfachen statischen Seiten nicht betrieben werden. Um bezahlte Abonnements und Zahlungen abzuwickeln, braucht es zustandsbasierte Logik wie Benutzerauthentifizierung, Prüfung des Abonnementstatus und Rechtemanagement; zum Schutz der Inhalte sind zudem Sicherheitsebenen wie die Echtzeit-Tokenvalidierung erforderlich, um unerlaubte Vervielfältigung oder unbefugten Zugriff zu verhindern. Darüber hinaus ist auch dynamische Datenverarbeitung nötig, um durch Personalisierung und A/B-Tests die User Experience und die Conversion Rate zu steigern.
All das gehört in den Bereich einer „ausgereiften Applikation“, und Frameworks sind dafür realistische Werkzeuge.
Natürlich lässt sich nicht jede Komplexität rechtfertigen. Wir sollten Komplexität in zwei Arten unterscheiden.
Unvermeidliche Komplexität: Komplexität mit klarem ROI, die bei der Umsetzung von Business-Funktionen entsteht, etwa Authentifizierung, Zahlung oder Personalisierung. Sie ist ein Kostenfaktor, den man in Kauf nehmen muss.
Zufällige Komplexität: unnötige Komplexität, die aus Entwicklerbequemlichkeit oder übermäßiger technischer Abstraktion entsteht. Sie ist technische Schuld und Verschwendung, die fortlaufend gemessen und beseitigt werden muss.
Erfolgreiche Services unterscheiden zwischen diesen beiden Arten und bauen darauf eine realistische Architektur auf. Das heißt: Die Frontlinie, in der Marketing und SEO wichtig sind, wird so leicht wie möglich gehalten, während interne Bereiche, in denen zentrale Transaktionen oder Personalisierungsfunktionen nötig sind, auf Framework-Basis abgesichert werden. Mit einer solchen Hybridstrategie lassen sich Geschwindigkeit und Funktionalität zugleich erreichen.
Der Originaltext konzentriert sich bei der Verschlechterung der User Experience allein auf die Framework-Kultur und blendet die „unvermeidlichen Anforderungen des Erlösmodells“ aus. Über Webentwicklung zu sprechen und diesen Punkt wegzulassen, ist letztlich so, als würde man nur darüber reden, den Gästen am Tisch „schnelle und leckere Gerichte“ zu servieren, während man so tut, als gäbe es die komplexe Küche und die Kasse, in der dafür bezahlt wird, gar nicht.
Nur weil das Web schwergewichtig geworden ist, kann man Frameworks nicht einfach pauschal verwerfen. Entscheidend sollte sein, wie effizient und mit welchen minimalen Kosten sich die vom Business geforderten Funktionen umsetzen lassen, um den Nutzern Mehrwert zu liefern.
Die koreanische Übersetzung finden Sie unten.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…