Vier Zeitalter der JavaScript-Frameworks

Bereits im Jahr 2012 begann ich, hauptsächlich in JavaScript zu programmieren. Ich habe einmal eine PHP-Anwendung, ein einfaches CMS und eine Website von Anfang bis Ende für ein lokales Unternehmen erstellt, und das Unternehmen beschloss, sie neu zu schreiben und einige Funktionen hinzuzufügen.

Der Projektmanager wollte, dass ich .NET verwende, zum Teil, weil er das wusste, aber auch, weil er wollte, dass sich die App wie eine native App anfühlt – keine Seitenaktualisierungen oder lange Wartezeiten auf Aktionsaktionen. Nach einiger Recherche und Prototyping überzeugte ich meinen Vorgesetzten, dass ich diese Dinge mit einem neuen JS-Framework tun könnte, das zu diesem Zeitpunkt gerade erst im Entstehen begriffen war.

Das erste Framework, das ich gewählt habe, war eigentlich Angular 1. Nachdem ich eine ziemlich große App erstellt und das Backend von FuelPHP verwendet hatte, bevor ich auf einige Probleme mit dem Router stieß – er flackerte, wann immer eine untergeordnete Route/Auslass neu gerendert wurde, und es fühlte sich wirklich so an, als würde er entworfen. Dieses Szenario wurde zu diesem Zeitpunkt nicht in Betracht gezogen .

​Später empfahl mir jemand Ruby on Rails + Ember. Nachdem ich es ausprobiert hatte, fand ich, dass es sehr gut funktionierte. Mir gefiel auch die Idee beider Frameworks, mir gefielen diese Community-Ökologien und insgesamt war es im Vergleich zu den damaligen Alternativen sehr produktiv.

Seitdem hat sich viel verändert – Frameworks sind entstanden und haben sich stark weiterentwickelt. Die Idee, dass man Anwendungen mit JavaScript im Browser erstellen kann, hat sich von einer Randerscheinung zur Standardpraxis entwickelt. Die von uns aufgebaute Infrastruktur hat sich völlig verändert und eröffnet neue Möglichkeiten.

In dieser Zeit gab es auch ziemlich viel Konkurrenz und Konflikte zwischen verschiedenen Ideen. Welches JavaScript-Framework verwendet werden soll, wie schreibt man CSS, funktionale vs. objektorientierte Programmierung, wie verwaltet man den Status am besten, welches Build-System oder Tool ist am flexibelsten und schnellsten usw. Rückblickend ist es komisch, wie wir oft über die falschen Dinge streiten und einige zukunftsweisende Überlegungen ignorieren. Natürlich ist dies auch eine Rückschau.

Deshalb wollte ich einen Rückblick machen, auf die letzten Jahrzehnte der JavaScript-Entwicklung zurückblicken und sehen, wie weit wir gekommen sind. Wir können es grob in vier Hauptepochen einteilen. :

• Ursprüngliche Ära
• Das erste Framework
• Komponentenzentrierte Ansichtsebene
• Full-Stack-Framework

Jede Ära hat ihre eigenen Themen und Kernwidersprüche und möchte gleichzeitig auch wichtige Lektionen lernen , Und stetig vorwärts gehen.

Heute geht die Debatte weiter. Wird das Web zu aufgebläht? Muss die durchschnittliche Website wirklich in React geschrieben werden? Sollten wir überhaupt JavaScript verwenden? Natürlich kann die Gegenwart nicht die Zukunft darstellen, und der bestehende Rahmen wird höchstwahrscheinlich in der Zukunft ersetzt, er basiert jedoch auch auf einigen bestehenden Perspektiven, die uns helfen, voranzukommen.

Original Years

JavaScript wurde erstmals 1995 veröffentlicht. Wie ich oben erwähnt habe, begann ich 2012, fast 20 Jahre später, kurz vor dem Beginn dessen, was ich die erste Framework-Ära nenne, JS zu schreiben. Sie können davon ausgehen, dass ich hier einen Großteil der Geschichte beschönige und dass diese Ära in viele Unterepochen unterteilt sein könnte, jede mit ihren eigenen Mustern, Bibliotheken, Build-Tools usw.

Das heißt, ich kann nicht über Dinge schreiben, die ich nicht erlebt habe. Als ich anfing, Frontend-Anwendungen zu schreiben, begann gerade eine neue Generation von Frameworks zu reifen. Angular.js, Ember.js, Backbone und mehr.

Davor waren Bibliotheken wie jQuery und MooTools die fortschrittlichste Technologie. Diese Bibliotheken waren zu ihrer Zeit wichtig – sie trugen dazu bei, die wichtigen Unterschiede in der Art und Weise, wie Browser JavaScript implementierten, auszugleichen.

Zum Beispiel ist die Art und Weise, wie IE Ereignisse implementiert, völlig anders als bei Netscape – Ereignisse sprudeln und Ereignisse erfassen. Aus diesem Grund implementieren unsere Standards heute endlich beide, aber bis dahin müssen wir Bibliotheken verwenden, um Code zu schreiben, der auf beiden Browsern funktioniert.

Diese Bibliotheken werden hauptsächlich zum Erstellen kleiner, unabhängiger Benutzeroberflächenkomponenten verwendet. Der Großteil der Geschäftslogik der Anwendung wird immer noch über Formulare und Standard-HTTP-Anfragen ausgeführt – das Rendern des HTML-Codes auf dem Server und die Bereitstellung an den Client.

Heutzutage gibt es keine nennenswerten Build-Tools, zumindest soweit ich weiß. JavaScript hatte damals keine Module (zumindest keine Standardmodule), daher gab es keine Möglichkeit, Code zu importieren. Alles ist global und es ist sehr schwierig, es zu organisieren.

In diesem Umfeld ist es verständlich, dass JS oft als Spielzeugsprache und nicht als etwas angesehen wird, das man zum Schreiben einer vollständigen Anwendung verwendet. Das häufigste, was wir damals gemacht haben, war, jQuery einzubauen, ein paar Skripte für einige UI-Widgets zu schreiben, und das war’s.

Mit der Zeit und der Einführung und Verbreitung von XHR begannen die Leute, Teile ihrer UI-Prozesse auf einer Seite unterzubringen, insbesondere für komplexe Prozesse, die mehrere Hin- und Her-Interaktionen zwischen Client und Server erfordern, aber die meisten davon die Anwendung verbleibt auf dem Server.

Dies steht in krassem Gegensatz zu der Zeit, als mobile Apps aufkamen. Von Anfang an waren mobile Apps für iOS und Android vollständige Anwendungen, die in No-Nonsense-Sprachen™ wie Objective C und Java geschrieben wurden. Darüber hinaus sind sie vollständig API-gesteuert – die gesamte UI-Logik befindet sich auf dem Gerät und die Kommunikation mit dem Server erfolgt ausschließlich im Datenformat. Dies führte zu einem besseren Benutzererlebnis und einer Explosion mobiler Apps, was direkt zu der heutigen Debatte darüber führte, ob Mobilgeräte oder das Web besser sind.

Das alles in JavaScript zu machen, galt zunächst als lächerlich. Doch mit der Zeit wurden die Bewerbungen immer ehrgeiziger. Soziale Netzwerke fügten Chat, DMs und andere Echtzeitfunktionen hinzu, Gmail und Google Docs zeigten, dass gleichwertige Desktop-Anwendungen im Browser geschrieben werden konnten, und immer mehr Unternehmen wandten sich dem Schreiben von Webanwendungen zu, weil das Web überall funktionierte und einfacher war -Befristete Wartung. Dies brachte die gesamte Branche voran – es war nun klar, dass JS zum Schreiben nicht trivialer Anwendungen verwendet werden konnte.

Damals verfügte JavaScript nicht über alle Funktionen, die es heute hat, alles war global und erforderte normalerweise das manuelle Herunterladen und Hinzufügen jeder externen Bibliothek zu einem statischen Ordner. NPM existierte noch nicht, Module existierten noch nicht und JS verfügte nicht über die Hälfte der Funktionalität, die es heute hat.

In den meisten Fällen ist jede Anwendung individuell angepasst, jede Seite verfügt über unterschiedliche Plugin-Einstellungen und jedes Plugin verfügt über ein anderes System zur Statusverwaltung und Rendering-Updates. Um diese Probleme zu lösen, erschien das früheste JavaScript-Framework. Etwa Ende der 2000er und Anfang der 2010er Jahre erschienen die ersten JS-Frameworks, die speziell für das Schreiben vollständiger clientseitiger Anwendungen entwickelt wurden. Mehrere berühmte Frameworks dieser Ära:

Backbone.js

Angular 1

1. Knockout.js
# 🎜🎜 #SproutCore
2. Ember.js
3. Meteor.js
5. Natürlich gibt es viele andere und wahrscheinlich noch ein paar größere in manchen Kreisen. Das sind diejenigen, an die ich mich erinnere, hauptsächlich weil Xiao Ming sie zum Programmieren verwendet hat und sie relativ beliebt sind.
6. Dies ist ein Generationenrahmen, der Neuland betritt. Einerseits war das, was sie versuchten, sehr ehrgeizig und viele dachten, es würde nie wirklich gelingen.

Es gibt viele Neinsager, die argumentieren, dass Single Page JS Applications (SPAs) grundsätzlich schlechter sind, und in vielerlei Hinsicht haben sie Recht – clientseitiges Rendering bedeutet, dass Bots diese Seiten nicht einfach crawlen können, und Der Benutzer muss einige Sekunden warten, bis die Anwendung überhaupt mit dem Zeichnen beginnen kann. Viele dieser Apps sind ein Albtraum in Sachen Barrierefreiheit und funktionieren überhaupt nicht, wenn JavaScript deaktiviert ist.

Andererseits haben wir keine Erfahrung mit der Erstellung vollständiger Anwendungen in JS, daher gibt es viele konkurrierende Ideen über den besten Ansatz. Die meisten Frameworks versuchen, das zu imitieren, was auf anderen Plattformen beliebt ist, sodass fast alle am Ende eine Iteration von Model-View-* sind. Model-View-Controller, Model-View-Produzent, Model-View-ViewModel und so weiter. Aber auf Dauer sind diese nicht wirklich erfolgreich – sie sind nicht besonders intuitiv und werden sehr schnell sehr kompliziert.

Dies ist auch eine Ära, in der wir wirklich anfangen, mit der Kompilierung von JavaScript-Anwendungen zu experimentieren. Node.js wurde 2009 veröffentlicht, und NPM folgte 2010 und führte Pakete für (serverseitiges) JavaScript ein.

CommonJS und AMD streiten darüber, wie JS-Module am besten definiert werden können, während Build-Tools wie Grunt, Gulp und Broccoli darüber streiten, wie diese Module zu einem lieferbaren Endprodukt kombiniert werden können.

Zum größten Teil handelt es sich hierbei um sehr allgemeine Tools im Task-Runner-Stil, die wirklich alles erstellen können, was zufällig zum Erstellen von JavaScript gehört – aber auch HTML, CSS/SASS/LESS und viele andere Dinge in Webanwendungen.

Allerdings haben wir viel aus dieser Zeit gelernt:

• URL-basiertes Routing ist die Grundlage. Anwendungen ohne dieses Routing unterbrechen das Web, daher muss dies von Anfang an im Framework berücksichtigt werden.
• Die Erweiterung von HTML durch eine Vorlagensprache ist eine leistungsstarke Abstraktionsebene. Auch wenn es manchmal etwas umständlich sein kann, erleichtert es die Synchronisierung der Benutzeroberfläche mit dem Status.
• Die Leistung von SPA ist sehr schlecht und das Web weist viele zusätzliche Einschränkungen auf, die native Anwendungen nicht haben. Wir müssen den gesamten Code über das Web veröffentlichen, per JIT verarbeiten und ihn dann ausführen, um unsere Anwendung zu starten, während die lokale Anwendung heruntergeladen und kompiliert wurde, was eine entmutigende Aufgabe ist.
• JavaScript hat als Sprache viele Probleme und muss wirklich verbessert werden, um die Dinge besser zu machen – Frameworks können das nicht alleine schaffen.
• Wir brauchen definitiv bessere Bauwerkzeuge, Module und Verpackungen, um Anwendungen in großem Maßstab zu schreiben.

Insgesamt ist diese Ära produktiv. Trotz der Nachteile sind die Vorteile der Entkopplung des Clients von der API mit zunehmender Komplexität der Anwendung enorm und in vielen Fällen ist das daraus resultierende Benutzererlebnis erstaunlich. Sofern keine besonderen Umstände eintreten, kann diese Ära weitergehen, und wir arbeiten immer noch an Ideen im MV*-Stil.

Aber dann tauchte plötzlich ein Asteroid auf, der das bestehende Paradigma in Stücke brach, ein kleines Aussterben verursachte und uns in die nächste Ära trieb – dieser Asteroid heißt React.

Komponentenzentrierte Ansichtsebene

Ich glaube nicht, dass React Komponenten erfunden hat, aber um ehrlich zu sein, bin ich mir nicht sicher, woher sie ursprünglich kamen. Aber es geht zumindest auf XAML in .NET zurück, und zu diesem Zeitpunkt begannen sich Webkomponenten als Spezifikation zu entwickeln. Letztendlich spielte es keine Rolle – sobald die Idee aufkam, wurde sie von allen wichtigen Frameworks sehr schnell übernommen.

Im Nachhinein macht das absolut Sinn – HTML erweitern, langlebige Zustände reduzieren, JS-Geschäftslogik direkt an Vorlagen binden (sei es JSX oder Handles oder Direktiven).

Komponentenbasierte Anwendungen entfernen die meisten Abstraktionen, die zur Erledigung der Aufgabe erforderlich sind, und vereinfachen den Code-Lebenszyklus erheblich – alles ist an den Lebenszyklus der Komponente und nicht an den Lebenszyklus der Anwendung gebunden, was bedeutet, dass Sie als Entwickler viel weniger Dinge denken müssen um.

Allerdings gab es damals auch einen Wandel: Frameworks begannen, sich als „Ansichtsebenen“ statt als vollwertige Frameworks zu bewerben. Anstatt alle für Front-End-Anwendungen erforderlichen Probleme zu lösen, konzentrieren sie sich auf die Lösung von Rendering-Problemen.

Andere Themen wie Routing, API-Kommunikation und Statusverwaltung bleiben dem Benutzer überlassen. Die berühmten Frameworks dieser Ära sind:

1. React.js
2. Vue.js
3. Svelte
4. Polymer.js

und viele andere. Wenn ich jetzt zurückblicke, denke ich, dass dies ein beliebtes Framework unter den Frameworks der zweiten Generation war, weil es wirklich zwei Hauptaufgaben erfüllte.

• Es schränkt den Umfang drastisch ein. Anstatt zu versuchen, alle diese Probleme im Voraus zu lösen, konzentriert sich der Kern des Frameworks auf das Rendering, und es können viele verschiedene Ideen und Richtungen für andere Funktionen innerhalb des breiteren Ökosystems untersucht werden. Es gibt viele schlechte Lösungen, aber es gibt auch gute Lösungen, die der nächsten Generation den Weg ebnen, die besten Ideen aus der Masse auszuwählen.
• Das erleichtert uns die Akzeptanz. Die Einführung eines vollständigen Frameworks zur Übernahme Ihrer gesamten Webseite bedeutet, dass Sie den Großteil Ihrer Anwendung neu schreiben müssen, was mit vorhandenen serverseitigen Monolithen nicht möglich ist. Mit Frameworks wie React und Vue können Sie kleine Teile davon Widgets oder Komponenten nacheinander in bestehende Anwendungen einfügen, sodass Entwickler ihren vorhandenen Code schrittweise migrieren können.

Diese beiden Faktoren haben zur schnellen Entwicklung von Frameworks der zweiten Generation geführt und die Frameworks der ersten Generation in den Schatten gestellt. Aus der Ferne scheint alles sinnvoll und eine vernünftige Entwicklung zu sein. Aber es war damals eine ziemlich frustrierende Erfahrung, dabei zu sein.

Zuallererst: Wenn wir darüber diskutieren, welches Framework wir bei der Arbeit verwenden sollen oder ob wir unsere Anwendung neu schreiben sollten, stoßen wir nicht oft auf ein solches Framework. Stattdessen heißt es oft: „Es ist schneller!“ oder „Es ist kleiner!“ oder „Es ist alles, was Sie brauchen!“

Es gibt auch eine Debatte über funktionale Programmierung und objektorientierte Programmierung, wobei viele Leute auf FP als Lösung für alle unsere Probleme verweisen. Um fair zu sein, diese Dinge sind wahr. Ein Nur-View-Layer-Framework ist (zunächst) kleiner, (zunächst) schneller und ist alles, was Sie brauchen (wenn Sie viele Dinge selbst erstellen oder zusammenfügen).

Natürlich lösen funktionale Programmiermuster viele Probleme, die JavaScript plagen, und ich denke, dass JS im Durchschnitt dadurch besser ist.

Die Realität ist jedoch, dass es überhaupt kein Wundermittel gibt. Anwendungen sind immer noch groß, aufgebläht und komplex, der Status ist immer noch schwer zu verwalten und grundlegende Probleme wie Routing und SSR müssen noch gelöst werden.

Viele von uns scheinen den Wunsch zu haben, die Lösung, die all diese Probleme zu lösen versucht, aufzugeben und sie durch eine Lösung zu ersetzen, die es den Lesern überlässt, es selbst herauszufinden.

Meiner Erfahrung nach ist dies auch eine gängige Praxis bei Ingenieursgruppen, die diese Änderung gerne annehmen, um ein neues Produkt oder eine neue Funktion zu liefern, und dann nicht die Zeit aufbringen, die für die vollständige Entwicklung all dieser zusätzlichen Funktionen erforderlich ist.

Das Ergebnis sind selbst erstellte Frameworks, die um diese Ansichtsebenen herum aufgebaut sind, die selbst aufgebläht, komplex und äußerst schwierig zu bedienen sind.

Ich denke, dass viele der Probleme, die Menschen mit SPA haben, auf dieses fragmentierte Ökosystem zurückzuführen sind, das genau zu dem Zeitpunkt entstanden ist, als die SPA-Nutzung explodiert. Ich stoße immer noch oft auf eine neue Website, die das Routing nicht richtig durchführt oder andere kleine Details nicht gut verarbeitet, und das ist absolut frustrierend.

Aber andererseits leistet das bestehende Full-Service-Framework der ersten Generation keine sehr gute Arbeit bei der Lösung dieser Probleme. Ein Teil davon ist auf viel technischen Schuldenlast zurückzuführen. Die Frameworks der ersten Generation wurden vor ES6, vor Modulen, vor Babel und Webpack erstellt, bevor wir viele Dinge herausgefunden hatten.

Iterative Weiterentwicklung ist sehr schwierig, und sie komplett neu zu schreiben, wie Angular es mit Angular 2 getan hat, zerstört die Dynamik ihrer Community.

Wenn es um JavaScript-Frameworks geht, stecken Entwickler also in einem Dilemma: Entweder sie entscheiden sich für eine All-in-One-Lösung, die langsam in die Jahre kommt, oder sie stürzen sich in die für alle kostenlose DIY-Hälfte des Frameworks und hoffen zum Besten.

Es war damals sehr frustrierend, hat aber am Ende viele Innovationen hervorgebracht. Das JavaScript-Ökosystem hat sich sehr schnell weiterentwickelt und eine Reihe weiterer wichtiger Änderungen sind eingetreten, während diese Frameworks ihre Best Practices herausgefunden haben.

• Transpiler wie Babel werden zur Norm und tragen zur Modernisierung der Sprache bei. Anstatt jahrelang auf die Standardisierung von Funktionen zu warten, können sie heute verwendet werden, und die Sprache selbst beginnt, Funktionen schneller und iterativer hinzuzufügen.
• ES-Module wurden standardisiert, sodass wir endlich damit begannen, moderne Build-Tools wie Rollup, Webpack und Parcel um sie herum zu entwickeln. Die importbasierte Bündelung wird langsam zur Norm, auch für Nicht-JS-Ressourcen wie Stile und Bilder, was die Konfiguration von Build-Tools erheblich vereinfacht und sie schlanker, schneller und umfassender macht.
• Da immer mehr APIs standardisiert werden, schließt sich die Lücke zwischen Node- und Web-Standards langsam, aber stetig. SSR wurde zu einer realen Möglichkeit und war dann etwas, was jede ernsthafte Anwendung tat, aber jedes Mal war es ein benutzerdefiniertes Setup.
• Edge Computing wird veröffentlicht und bietet JavaScript-basierten Serveranwendungen die Verteilungs-/Reaktionszeitvorteile von SPA (zuvor wurden Spas in der Regel schneller geladen, da es sich um statische Dateien im CDN handelte, auch wenn das vollständige Laden und Beenden länger dauerte).

Am Ende dieser Ära bleiben noch einige Fragen offen. Staatsverwaltung und Reaktionsfähigkeit waren (und sind) heikle Themen, auch wenn wir über bessere Modelle als zuvor verfügen.

Leistung ist immer noch ein schwieriges Thema und obwohl sich die Dinge verbessern, gibt es immer noch viele, viele aufgeblähte SPAs.

Auch die Barrierefreiheit hat sich verbessert, ist für viele Ingenieursbetriebe aber immer noch oft ein Nebengedanke. Aber diese Änderungen ebneten den Weg für die nächste Generation von Frameworks, in die wir meiner Meinung nach jetzt eintreten.

Full-Stack-Framework

Persönlich ist die letzte Framework-Ära ganz leise angekommen. Ich denke, das liegt daran, dass ich die letzten vier Jahre damit verbracht habe, mich mit den Interna der Rendering-Ebene von Ember auseinanderzusetzen und zu versuchen, die oben erwähnten technischen Probleme zu lösen, die es als Framework der ersten Generation (noch) beeinträchtigt haben. Es liegt aber auch daran, dass es subtiler ist, da alle diese Frameworks der dritten Generation auf den View-Layer-Frameworks der vorherigen Generation basieren. Zu diesen Frameworks gehören:

1. Next.js (React)
2. Nuxt.js (Vue)
3. Remix (React)
4. SvelteKit (Svelte)
5. Gatsby (React)
6. Astro (Any)

Es begann mit der Reife und Konsolidierung der Ansichtsschicht. Da wir uns nun alle einig sind, dass Komponenten auf dem Kern aufbauen, ist es sinnvoll, mit der Standardisierung anderer Teile der Anwendung zu beginnen – Router, Build-Systeme, Ordnerstrukturen usw.

Langsam beginnen diese Meta-Frameworks, die gleichen sofort einsatzbereiten Funktionen wie die All-in-One-Lösungen der ersten Generation aufzubauen, indem sie die besten Muster aus ihren jeweiligen Ökosystemen auswählen und sie integrieren, wenn sie ausgereift sind.

Dann gingen sie noch einen Schritt weiter.

Vorher hat sich SPA nur auf den Kunden konzentriert. SSR ist etwas, das jedes Framework lösen möchte, aber nur als Optimierung, als Möglichkeit, gerendert und letztendlich ersetzt zu werden, wenn die Megabytes von JS endlich geladen sind.

Nur ein Framework der ersten Generation wagte es, weiterzudenken, Meteor.js, aber seine Idee von isomorphem JS wurde nie wirklich verwirklicht.

Aber als die Größe und Komplexität der Anwendungen zunahm, wurde die Idee neu aufgegriffen.

Wir haben festgestellt, dass es tatsächlich sehr nützlich ist, Backend und Frontend miteinander zu koppeln, damit Sie beispielsweise API-Geheimnisse für bestimmte Anfragen verbergen, Header bei der Rückgabe von Seiten ändern und API-Anfragen als Proxy ausführen können. Da Node und Deno immer mehr Webstandards implementieren und die Kluft zwischen serverseitigem JS und clientseitigem JS jedes Jahr kleiner wird, sieht es langsam so aus, als wäre es doch keine so verrückte Idee. Kombinieren Sie das mit Edge-Computing und erstaunlichen Werkzeugen, dann ergibt sich ein unglaubliches Potenzial.

Die neueste Generation von Frameworks nutzt dieses Potenzial voll aus, indem sie Client und Server nahtlos miteinander verbindet, und ich kann nicht genug betonen, wie großartig sich das anfühlt. Ich weiß nicht, wie oft ich mich in den letzten 9 Monaten meiner Arbeit mit SvelteKit hingesetzt und mir gesagt habe: „Das sollten wir die ganze Zeit tun.“

Hier sind einige der Aufgaben, die ich erledigen muss Ich bin kürzlich mit diesem Setup auf diese Aufgaben gestoßen, die unglaublich einfach werden.

• Hinzufügen von serverseitigem OAuth zu unserer Anwendung, sodass das Authentifizierungstoken niemals den Server verlässt, sowie eines API-Proxys, der das Token hinzufügt, wenn Anfragen an unsere API gestellt werden.
• Proxy bestimmter Routen direkt zu unserem CDN, damit wir statische HTML-Seiten hosten können, die in jedem anderen Framework erstellt wurden, sodass Benutzer ihre eigenen benutzerdefinierten Seiten erstellen können (ein Service, den wir für einige Kunden anbieten).
• Fügen Sie ein paar verschiedene einmalige API-Routen hinzu, wenn wir einen externen Dienst verwenden müssen, der einen Schlüssel erfordert (es ist nicht erforderlich, unserer API eine ganz neue Route hinzuzufügen und sich mit Backend-Mitarbeitern abzustimmen).
• Wir verlagern unsere Nutzung von LaunchDarkly auf die Serverseite, damit wir weniger JS laden und so die Gesamtkosten senken können.
• Leiten Sie unsere Sentry-Anfragen über das Backend-Routing weiter, damit wir Fehler erkennen können, die aufgrund von Werbeblockern nicht gemeldet werden.

Und das ist nur die Spitze des Eisbergs. Es gibt wirklich viele coole Dinge an diesem Muster. Das größte davon ist, dass es die Idee der progressiven Verbesserung neu belebt, indem es die kombinierten Funktionen von Server und Client nutzt, um es dem Client zu ermöglichen, auf das Basismuster zurückzugreifen, wenn der Benutzer es deaktiviert JavaScript HTML + HTTP.

Als ich anfing, in Spas zu arbeiten, hatte ich selbst diese Praxis völlig aufgegeben, weil ich dachte, sie sei der Trend der Zukunft, aber es ist wirklich cool, dass wir möglicherweise eine Welt sehen könnten, in der sie ein Comeback feiert.

Dies sind neue Funktionen. Aus Erfahrung klassifiziere ich diese Frameworks als Frameworks der neuen Generation. Probleme, die früher schwer oder gar nicht zu lösen waren, werden nun trivial und erfordern nur eine geringfügige Änderung der Antwortverarbeitungslogik.

Zuverlässige Leistung und Benutzererfahrung sind sofort einsatzbereit und erfordern keine zusätzliche Konfiguration. Anstatt einen völlig neuen Dienst aufzubauen, können wir bei Bedarf einige zusätzliche Endpunkte oder Middleware hinzufügen. Das hat mein Leben verändert.

Ich denke, diese Generation löst auch einige der Hauptkonfliktpunkte zwischen den Frameworks der ersten und zweiten Generation und ihren Benutzern.

Es begann mit einem Wandel hin zur Null-Konfigurations-Terminologie, aber ich denke, dass dies letztendlich auf die Reife und Stabilität des Ökosystems rund um Frameworks der zweiten Generation zurückzuführen ist, was auch einen kulturellen Wandel darstellt.

Frameworks der dritten Generation versuchen nun wieder, eine All-in-One-Lösung zu sein und alle grundlegenden Probleme zu lösen, die wir als Front-End-Entwickler lösen müssen – nicht nur das Rendern.

Jetzt hat man mehr denn je das Gefühl, dass die Community bei all den vielen Problemen, mit denen SPA zu kämpfen hat, einer Meinung ist und, was noch wichtiger ist, sie gemeinsam lösen kann.

Wohin gehen wir als nächstes?

Insgesamt denke ich, dass sich die JavaScript-Community in die richtige Richtung bewegt. Wir haben endlich ausgereifte Lösungen für den Aufbau kompletter Anwendungen von Grund auf entwickelt, die nicht „nur eine Ansichtsschicht“ sind.

Wir fangen endlich an, an der gleichen Startlinie zu konkurrieren wie native App-SDKs und bieten ein komplettes Toolkit sofort einsatzbereit.

Wir haben in diesem Bereich noch viel zu tun. Barrierefreiheit ist in der SPA-Welt seit langem ein nachträglicher Gedanke, und außerhalb von GraphQL denke ich immer noch, dass Datengeschichten etwas Arbeit gebrauchen könnten (ob es Ihnen gefällt oder nicht, der größte Teil des Webs läuft immer noch auf REST).

Aber der Trend stimmt, und wenn wir uns weiter in Richtung gemeinsamer Lösungen bewegen, denke ich, dass wir diese Probleme besser lösen können als bisher.

Ich freue mich auch über das Potenzial, diese Muster weiter in die Webplattform selbst zu integrieren. Webkomponenten werden immer noch im Stillen iteriert und arbeiten an Problemen wie SSR und der Abschaffung der globalen Registrierung, wodurch sie besser mit diesen Frameworks der dritten Generation kompatibel werden.

In der anderen Richtung kann WebAssembly dieses Muster auf unglaubliche Weise iterieren. Stellen Sie sich vor, Sie könnten ein Full-Stack-Framework in jeder Sprache schreiben.

Isomorphe Sprachen wie Rust, Python, Swift, Java usw. können die Barriere zwischen Vorder- und Rückseite endlich auf nahezu Null reduzieren – nur eine kleine HTML-Vorlage am Rande Ihres Systems (was uns ironischerweise fast dazu bringt, den Kreis zu umgehen, wenn auch mit einer besseren Benutzererfahrung).

Meine größte Hoffnung hier ist, dass wir jeden Tag die Ära der Fragmentierung und die Ära neuer JS-Frameworks hinter uns lassen. Freiheit und Flexibilität führen zu Innovationen, führen aber auch zu verwirrenden, unzusammenhängenden und oft grundlegend fehlerhaften Erfahrungen im Web.

Wenn Entwickler zwischen mehr als 50 Optionen wählen und diese mit begrenzten Ressourcen und engen Fristen zusammensetzen müssen, ist dies die Erfahrung, die wir sehen, und sie macht Sinn. Einige Apps sind schnell, konsistent, zuverlässig und machen Spaß, während andere frustrierend, verwirrend, langsam und kaputt sind.

Wenn wir Entwicklern Tools zur Verfügung stellen könnten, die einfacher zu verwenden sind und standardmäßig die richtigen Dinge tun, wären Websites im Allgemeinen vielleicht besser und das Erlebnis im Allgemeinen reibungsloser.

Es wird nicht jede Website reparieren – keine Menge Code kann schlechtes UX-Design reparieren. Aber es wird eine gemeinsame Grundlage schaffen, sodass jede Website etwas besser startet und jeder Entwickler mehr Zeit hat, sich auf andere Dinge zu konzentrieren.

Das obige ist der detaillierte Inhalt vonVier Zeitalter der JavaScript-Frameworks. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!