Ein paar interessante Artikel, die gerade die Runde machen
- Tom MacWrite: Second-guessing the modern web
- Rich Harris: In defense of the modern web
Ich mag Toms Behauptung, dass React (das er als Platzhalter für JavaScript-Frameworks im Allgemeinen verwendet) einen idealen Anwendungsfall hat.
Es gibt einen Sweet Spot für React: in mäßig interaktiven Benutzeroberflächen. Komplexe Formulare, die sofortiges Feedback erfordern, Benutzeroberflächen, die sich bewegen und sofort reagieren müssen. Dort glänzt es.
Wenn ich mir für die Welt des Webdesigns und der Webentwicklung etwas wünsche, dann, dass wir besser darin werden, die richtigen Werkzeuge für die jeweilige Aufgabe auszuwählen.
Ich habe gehört, wie mehrere Leute sich darauf konzentriert haben.
Ich kann zum Beispiel garantieren, dass dieser Blog schneller ist als jeder Gatsby-Blog (und viel Liebe an das Gatsby-Team), weil nichts, was eine statische React-Seite tun kann, sie schneller macht als eine statische Nicht-React-Seite.
Eine Reaktion war verdammt ja. React ist ein Haufen JavaScript und macht viele Dinge, aber es verleiht keine Superkräfte, die das Web schneller machen als ohne es. Eine andere Reaktion war: Naja, eigentlich schon. Das ist irgendwie der Sinn von SPAs: man muss die Seite nicht neu laden. Stattdessen können wir eine gekürzte Netzwerkanfrage für die neuen Daten machen, die für eine neue Seite benötigt werden, und nur das Notwendige neu rendern.
Rich geht noch weiter darauf ein.
Wenn ich auf einen Link auf Toms JS-freier Website tippe, wartet der Browser zuerst, um zu bestätigen, dass es sich um einen Tipp und nicht um ein Streichen/Wischen handelte, macht dann eine Anfrage, und dann müssen wir auf die Antwort warten. Mit einer Framework-generierten Website mit clientseitigem Routing können wir interessantere Dinge tun. Wir können fundierte Vermutungen basierend auf Analysen darüber anstellen, mit welchen Dingen der Benutzer wahrscheinlich interagieren wird, und die Logik und Daten dafür vorladen. Wir können Anfragen starten, sobald der Benutzer den Link zum ersten Mal berührt (oder darüber schwebt), anstatt auf die Bestätigung eines Taps zu warten – im schlimmsten Fall haben wir einige Dinge geladen, die später nützlich sein werden, wenn er sie tatsächlich tippt. Wir können besseres visuelles Feedback geben, dass das Laden stattfindet und eine Übergang bevorsteht. Und wir müssen nicht den gesamten Inhalt der Seite laden – oft reicht ein kleines JSON aus, weil wir den JavaScript-Code für die Seite bereits haben. Diese Dinge sind mit der Hand teuflisch schwer zu machen.
Das macht diese Dinge so streitbar. Jeder hat gute Punkte. Wenn wir versuchen, für das gesamte Web zu sprechen, ist es für uns alle schwierig, uns zu einigen. Aber das Web ist zu groß für pauschale, weitreichende Behauptungen.
Greifen die Leute zu oft zu React-basierten SPAs? Wahrscheinlich, aber das nicht ohne Grund. Es gibt dort Innovationen, die Leute anziehen. Die Frage ist, wie können wir es verbessern?
Aus einer Front-of-the-Front-End-Perspektive ist die Tatsache, dass Front-End-Frameworks wie React uns ermutigen dazu zwingen, ein Frontend in Komponenten zu schreiben, an sich schon überzeugend.
Es gibt Optimismus und Pessimismus in beiden Beiträgen. Die abschließenden Sätze beider sind stark unterschiedlich.
Das richtige Werkzeug für die Aufgabe zu verwenden ist alles schön und gut, aber Webentwickler möchten nicht alle paar Monate eine neue Sprache, ein neues Framework oder eine neue Datenbank lernen.
Ja, manchmal verwenden wir vielleicht React mit einem CMS, um eine Website zu erstellen, die mit einem Static Site Generator schneller sein könnte. Manchmal bauen wir etwas mit jQuery, wenn es bessere/neuere Alternativen gibt, und manchmal entscheiden wir uns vielleicht, eine REST-API zu bauen, wenn GraphQL besser geeignet wäre, oder SASS zu installieren, um sehr einfaches CSS zu machen.
Der Punkt ist, dass wir denselben Technologie-Stack für mehr als ein Projekt verwenden wollen, weil wir die Chance haben wollen, darin gut zu werden.
Wir wollen nicht jedes neue Projekt mit einem Stapel Bücher oder dem Durchwaten von GitHub und Stack Overflow beginnen, nur um die Grundlagen zu schaffen, bevor wir überhaupt mit der eigentlichen Arbeit beginnen können.
Mein aktueller Stack ist React mit NextJS für Websites und Create-React-App für SPAs. Node/Express im Backend, MSSQL und Storyblok, wenn ich ein CMS brauche.
Sind das die richtigen Werkzeuge für die Aufgabe bei jedem Projekt? Natürlich nicht, aber ich werde in all diesen gut und werde stundenweise bezahlt, also habe ich keine Zeit, für jedes Projekt einen neuen Stack zu lernen.
Aus demselben Grund kenne ich viele Leute, die WordPress bei jedem Projekt verwenden, obwohl es selten, wenn überhaupt, das richtige Werkzeug für die Aufgabe ist.
Was ist die Antwort? Müssen wir alle jedes Werkzeug lernen, damit wir immer das beste für die Aufgabe verwenden können, oder müssen die Werkzeuge und Frameworks flexibler sein, damit sie die größtmögliche Bandbreite an Anwendungsfällen abdecken?
Stellen Sie sich vor, Webentwickler müssten nur einen einzigen Stack lernen, der flexibel genug für jedes Projekt wäre, an dem sie arbeiten müssten, von kleinen, unveränderlichen statischen Websites bis hin zu riesigen dynamischen Progressive Web Apps….
Nicht so schnell. Mit "jeder hat Recht" abzuschließen, ist ein billiger Sieg. Die Anwendung, an der ich in meinem Job arbeite, wurde mehrmals neu geschrieben, angefangen mit jQuery, dann volles serverseitiges CSHTML und dann volle statische Seiten mit React und einer API. Auf den ersten Blick scheint das Statische mit React am schnellsten zu sein – die Seite lädt schnell (aber wir haben auch viel CDN-Caching), läuft reibungslos, Animationen sind großartig – alles großartig.
Aber raten Sie mal? Sobald ich die App in meinem Browser lade, beginnen die Lüfter meines Laptops verrückt zu drehen. Außerdem war der Code anfangs sehr sauber und es war eine Freude, damit zu arbeiten – aber jetzt ist er genauso beschissen wie das serverseitige CSHTML. Ich denke, es ist im Moment beschissener zu arbeiten als mit jQuery, aber das ist lange her und ich könnte mich irren. Und natürlich sieht/funktioniert es so, weil der Code nicht von Universitätsprofessoren geschrieben wird, die immer in der Lage sind, Code perfekt zu organisieren. Der Code wird von mehreren Teams geschrieben, einige davon in anderen Ländern, einige Auftragnehmer und so weiter.
Und Sie sehen genau, das ist das Problem: Unter idealen Bedingungen wäre React schnell und sauber, aber in alltäglichen Arbeitsplätzen lässt React die CPU auf 100% laufen und der Code sieht scheiße aus. Es ist nicht per se ein React-Problem. Es ist nicht per se ein React-Router-Problem. Es ist nicht per se ein React-Async-Actions-Problem, noch Redux, noch Webpack, noch die ganze Million Abhängigkeiten im Node_modules-Ordner, für den wir täglich Snyk audit verwenden müssen. Nein, nein, das Problem ist, dass all diese Werkzeuge die Entwicklungsumgebung so hart zum Kotzen machen, dass ein einfaches serverseitiges HTML (oder CSHTML) diese ganze Stack die ganze Zeit aussticht.
Webpack braucht Minuten zum Bauen? Zumindest für unsere App. Und es kann manchmal den Node_modules-Ordner nicht löschen, weil er vom selben Build-System irgendwo anders verwendet wird? Sie sehen, all diese Probleme waren im CSHTML-Land unbekannt. Oder im jQuery-Land. Oder verdammt, im reinen JavaScript-Land, jetzt, wo wir das Jahr 2020 erreicht haben. Also ja, ich habe viel gegen React. Es ist ein Betrug. Es soll gut sein, aber es macht Ihre gesamte Entwicklungsumgebung zu einem Witz.
Entschuldigung für den Ausbruch übrigens…
Anstatt sich ausschließlich auf Leistungsideale zu konzentrieren, sollte man auch die Kosten für Entwicklung und Wartung, die Geschwindigkeit, mit der man sich an Marktveränderungen und neue Anforderungen anpassen kann, und so weiter berücksichtigen.
Das HTML (und CSS) ist die sichtbare Benutzeroberfläche. Meiner Meinung nach gibt es wahrscheinlich nur ein gutes Argument dafür, die sichtbare Benutzeroberfläche serverseitig zu rendern, und das ist SEO. Wenn Sie Ihre *Benutzer*-Oberfläche auf der *Benutzer*-Seite implementieren können, warum sollten Sie das nicht tun? Es ist von Natur aus einfacher, schneller, leichter zu erstellen und zu ändern, bandbreiteneffizienter und gesunder Menschenverstand – der Versuch, UI-Probleme, die vom Benutzer/Client entfernt sind, zu lösen, fügt eine Schicht von Komplexität, Leistungsbeschränkungen hinzu und normalerweise nur viel "Unordnung" durch den Versuch, lose Enden (hauptsächlich Interaktions-UI) auf der Client-Seite zu binden.
Ein statisches Frontend und einige APIs sind meiner Erfahrung nach immer einfacher und wartungsfreundlicher als die Alternative. Ich greife persönlich nicht zu serverseitigem Rendering, es sei denn, es gibt Inhalte auf einer Seite, die indiziert werden können. Ansonsten finde ich keine überzeugenden Gründe, HTML vom Server aus zu erzeugen.
Aus meiner Sicht haben Client-Side UI-Frameworks und APIs die Webentwicklung insgesamt einfacher, produktiver und angenehmer gemacht als früher. Ich kann ehrlich gesagt nicht wirklich nachvollziehen, warum jemand das Gegenteil behaupten würde?
Schöne Zusammenfassung. Ich stimme zu, dass beide gute Punkte hatten. Es ist gesund, regelmäßig nachzudenken und zu bewerten. Ich spüre, dass die Essenz von Toms Beitrag genau das ist. Ich mag auch, was Rich und sein Team mit Svelte machen. Dann, kombiniert mit den Nachrichten über Deno, habe ich das Gefühl, dass JS anfängt, Anzeichen der dritten Welle zu zeigen (wie Rich in einem seiner Vorträge erwähnt).
Ich denke, es läuft alles darauf hinaus, wie der Entwickler die von React angebotenen Werkzeuge implementiert, sowie die Web-App selbst. Reaktive JS (Vue oder React etc.) gibt Ihnen kurz gesagt die Macht, mehr zu tun. Es liegt an Ihnen und wie Sie diese 'Macht' einsetzen.
Es ist erwähnenswert, dass auf einer statischen Website Seiten beim Hover vorab geladen werden können, ohne manuelle Arbeit, indem man instant.page integriert. Mit etwas manueller Arbeit können Sie es in eine SPA mit viel weniger JavaScript-Code im Vergleich zu React umwandeln, indem Sie Barba.js verwenden. (Ich würde gerne eine minimalistischere Version von Barba.js sehen, die sich nur auf den SPA-Aspekt ohne Animationen konzentriert, aber ich habe noch keine gefunden.)
Ich habe React und das dazugehörige Ökosystem – Build-/Deployment-Praktiken und weit verbreitete UI-Designmuster – intensiv zu hassen gelernt.
Diese Frameworks führen subtile Probleme und Schwierigkeiten in Websites ein, die entsetzlich ärgerlich sein können, aber die Leistung ist immer gerade gut genug, dass ihnen nie Aufmerksamkeit gewidmet wird.
Das Framework und der Build-Prozess generieren Seitenstrukturen, die überflüssig, verschleiert und für Power-User des Webs sehr unfreundlich zur Anpassung sind.
Und "Responsive Design" ist zu "Mobile Design" geworden. Die meisten Seiten sehen auf dem Desktop absolut scheiße aus. Daran ist nichts "responsiv" mehr, es ist nur noch ein Schlagwort geworden. Das ist die Folge von Faulheit oder "gut genug"-Mentalität. Entwickler verlassen sich auf Werkzeuge und vorgefertigte Komponenten, um eine Arbeit zu erledigen, die nicht automatisiert werden kann. Es ist nicht trivial, eine Website zu entwerfen, die wirklich responsiv ist und in zwei sehr unterschiedlichen Seitenverhältnissen gut funktioniert.
*Twitter.com* ist ein Paradebeispiel.
Mehr als die Hälfte meines Bildschirms ist leer. "Responsiv", mein Hintern.
Die Suchfunktion des Browsers funktioniert auf der Seite nicht, weil das Framework beim Scrollen Elemente von der Seite entfernt. Schlechte UX.
Die Seitenstruktur ist ein höllischer Baum aus Hunderten von verschachtelten Divs und unsinnigen CSS-Klassen. Wenn ich etwas ändern will, muss ich eine Stunde damit verbringen, nur zu analysieren, was zum Teufel passiert.
Eine andere Seite, die ich häufig besuche – deviantArt – hat kürzlich ein neues Redesign mit React eingeführt. Es leistet jetzt schlechter, bietet eine schlechtere Benutzererfahrung und hat eine Menge Funktionen der alten Version verloren.
Und das ist ein Trend in diesem neuen "modernen Web" und ich hasse es absolut.
Aus meiner Sicht als Webentwickler und Web-Power-User sind diese Frameworks nur eine neuartige Art, mehr Kompromisse einzugehen. Eine Illusion von Produktivität.