Preis für JavaScript-Frameworks

Es gibt keinen schnelleren Weg, eine Website zu verlangsamen (Wortspiel beabsichtigt), als eine Menge JavaScript-Code darauf zu verwenden. Wenn Sie JavaScript verwenden, müssen Sie dafür mindestens das Vierfache der Projektleistung bezahlen. So lädt der JavaScript-Code der Website die Systeme der Benutzer:

• Herunterladen einer Datei über das Netzwerk.
• Parsen und Kompilieren des entpackten Quellcodes nach dem Download.
• Ausführung von JavaScript-Code.
• Speicherverbrauch.

Diese Kombination stellt sich heraus sehr teuer.

Und wir integrieren immer mehr JS-Code in unsere Projekte. Während Unternehmen auf Websites umsteigen, die auf Frameworks und Bibliotheken wie React, Vue und anderen basieren, machen wir die Kernfunktionalität von Websites sehr stark von JavaScript abhängig.

Ich habe viele sehr umfangreiche Websites gesehen, die JavaScript-Frameworks verwenden. Aber meine Sicht auf das Thema ist sehr voreingenommen. Tatsache ist, dass sich die Unternehmen, mit denen ich zusammenarbeite, gerade deshalb an mich wenden, weil sie mit komplexen Problemen im Bereich der Website-Performance konfrontiert sind. Infolgedessen wurde ich neugierig, wie häufig dieses Problem auftritt und welche „Strafen“ wir zahlen, wenn wir das eine oder andere Framework als Grundlage für eine bestimmte Website auswählen.

Das Projekt hat mir geholfen, das herauszufinden. HTTP-Archiv.

Daten

Das HTTP-Archivprojekt verfolgt insgesamt 4308655 Links zu regulären Desktop-Sites und 5484239 Links zu mobilen Sites. Zu den vielen mit diesen Links verbundenen Metriken gehört eine Liste der Technologien, die auf den jeweiligen Websites zu finden sind. Das bedeutet, dass wir Tausende von Websites testen können, die verschiedene Frameworks und Bibliotheken verwenden, und erfahren, wie viel Code sie an Kunden senden und wie viel Last dieser Code auf den Systemen der Benutzer verursacht.

Ich habe Daten vom März 2020 gesammelt, das waren die aktuellsten Daten, auf die ich Zugriff hatte.

Ich habe beschlossen, aggregierte HTTP-Archivdaten aller Websites mit Daten von Websites zu vergleichen, die mit React, Vue und Angular gefunden wurden, obwohl ich auch über die Verwendung anderen Quellmaterials nachgedacht habe.

Um es interessanter zu machen, habe ich dem Quelldatensatz auch Websites hinzugefügt, die jQuery verwenden. Diese Bibliothek erfreut sich immer noch großer Beliebtheit. Es führt auch einen anderen Ansatz für die Webentwicklung ein als das Single Page Application (SPA)-Modell von React, Vue und Angular.

Links im HTTP-Archiv, die Websites darstellen, die nachweislich interessante Technologien verwenden

Framework oder Bibliothek
Links zu mobilen Websites
Links zu regulären Websites

jQuery
4615474
3714643

Reagieren
489827
241023

Vue
85649
43691

Angular
19423
18088

Hoffnungen und Träume

Bevor wir zur Datenanalyse übergehen, möchte ich darüber sprechen, was ich mir erhoffe.

Ich glaube, dass Frameworks in einer idealen Welt über die Erfüllung der Bedürfnisse von Entwicklern hinausgehen und dem durchschnittlichen Benutzer, der mit unseren Websites arbeitet, einen spezifischen Nutzen bieten sollten. Leistung ist nur einer dieser Vorteile. Hier kommen Zugänglichkeit und Sicherheit ins Spiel. Aber das ist nur das Wichtigste.

In einer idealen Welt sollte es also ein Framework geben, das die Erstellung einer leistungsstarken Website erleichtert. Dies sollte entweder aufgrund der Tatsache erfolgen, dass das Framework dem Entwickler eine angemessene Grundlage für den Aufbau eines Projekts bietet, oder aufgrund der Tatsache, dass es der Entwicklung Einschränkungen auferlegt und Anforderungen an ihn stellt, die die Entwicklung von etwas, das sich dreht, erschweren erweist sich als langsam.

Die besten Frameworks sollten beides tun: eine gute Basis bieten und der Arbeit Einschränkungen auferlegen, damit Sie ein anständiges Ergebnis erzielen können.

Die Analyse der Medianwerte der Daten wird uns nicht die Informationen liefern, die wir brauchen. Und tatsächlich lässt dieser Ansatz unsere Aufmerksamkeit außen vor sehr wichtig. Stattdessen habe ich Prozentsätze aus den Daten abgeleitet, die ich hatte. Dies sind 10, 25, 50 (Median), 75, 90 Perzentile.

Ich interessiere mich besonders für das 10. und 90. Perzentil. Das 10. Perzentil stellt die allerbeste Leistung (oder zumindest mehr oder weniger nahe an der Besten) für ein bestimmtes Framework dar. Mit anderen Worten bedeutet dies, dass nur 10 % der Websites, die ein bestimmtes Framework verwenden, dieses Niveau oder höher erreichen. Das 90. Perzentil hingegen ist die Kehrseite der Medaille – es zeigt uns, wie schlimm es werden kann. Das 90. Perzentil sind die zurückgebliebenen Websites – die unteren 10 % der Websites, die den meisten JS-Code haben oder die längste Zeit für die Verarbeitung ihres Codes im Hauptthread haben.

Mengen an JavaScript-Code

Zunächst ist es sinnvoll, die Größe des JavaScript-Codes zu analysieren, der von verschiedenen Websites über das Netzwerk übertragen wird.

Die Menge des an mobile Geräte übertragenen JavaScript-Codes (KB).

Perzentile
10
25
50
75
90

Alle Standorte
93.4 
196.6 
413.5 
746.8 
1201.6 

jQuery-Sites
110.3 
219.8 
430.4 
748.6 
1162.3 

Vue-Sites
244.7 
409.3 
692.1 
1065.5 
1570.7 

Angular-Sites
445.1 
675.6 
1066.4 
1761.5 
2893.2 

Reagieren Sie auf Websites
345.8 
441.6 
690.3 
1238.5 
1893.6 

Menge des an mobile Geräte gesendeten JavaScript-Codes

Menge des an Desktop-Geräte übertragenen JavaScript-Codes (KB).

Perzentile
10
25
50
75
90

Alle Standorte
105.5 
226.6 
450.4 
808.8 
1267.3 

jQuery-Sites
121.7 
242.2 
458.3 
803.4 
1235.3 

Vue-Sites
248.0 
420.1 
718.0 
1122.5 
1643.1 

Angular-Sites
468.8 
716.9 
1144.2 
1930.0 
3283.1 

Reagieren Sie auf Websites
308.6 
469.0 
841.9 
1472.2 
2197.8 

Menge des an Desktop-Geräte gesendeten JavaScript-Codes

Wenn wir nur über die Größe des JS-Codes sprechen, den Websites an Geräte senden, sieht alles so aus, wie Sie es erwarten. Wenn nämlich eines der Frameworks verwendet wird, bedeutet dies, dass selbst im Idealfall das Volumen des JavaScript-Codes der Website zunimmt. Dies ist nicht überraschend – Sie können nicht ein JavaScript-Framework zur Grundlage einer Website machen und erwarten, dass der Umfang des JS-Codes des Projekts sehr gering ist.

Das Bemerkenswerte an diesen Daten ist, dass einige Frameworks und Bibliotheken als besserer Ausgangspunkt für ein Projekt angesehen werden können als andere. Websites mit jQuery sehen am besten aus. Auf Desktop-Versionen von Websites enthalten sie 15 % mehr JavaScript als alle Websites und auf Mobilgeräten 18 % mehr. (Zugegebenermaßen liegt hier eine gewisse Datenkorruption vor. Tatsache ist, dass jQuery auf vielen Websites vorhanden ist, daher ist es nur natürlich, dass solche Websites enger mit der Gesamtzahl der Websites verknüpft sind als andere. Dies hat jedoch keinen Einfluss auf die Rohdaten Für jedes Framework werden Daten ausgegeben.)

Obwohl der Anstieg des Codevolumens um 15–18 % eine bemerkenswerte Zahl ist, kann man im Vergleich mit anderen Frameworks und Bibliotheken zu dem Schluss kommen, dass die von jQuery erhobene „Steuer“ sehr niedrig ist. Angular-Sites im 10. Perzentil senden 344 % mehr Daten an den Desktop als alle Sites und 377 % mehr an Mobilgeräte. React-Sites sind am zweithäufigsten und senden 193 % mehr Code an den Desktop als alle Sites und 270 % mehr an Mobilgeräte.

Zuvor habe ich erwähnt, dass die Verwendung eines Frameworks zwar bedeutet, dass eine bestimmte Menge Code in das Projekt eingebunden wird, ich aber zu Beginn der Arbeit daran hoffe, dass das Framework den Entwickler irgendwie einschränken kann. Insbesondere geht es um die Begrenzung der maximalen Codemenge.

Interessanterweise folgen jQuery-Sites dieser Idee. Während sie beim 10. Perzentil etwas schwerer sind als alle Websites (um 15–18 %), sind sie beim 90. Perzentil mit etwa 3 % sowohl auf dem Desktop als auch auf Mobilgeräten etwas leichter. Das soll nicht heißen, dass dies ein sehr bedeutender Vorteil ist, aber man kann sagen, dass jQuery-Sites zumindest nicht über große JavaScript-Codegrößen verfügen, selbst in ihren größten Versionen.

Das Gleiche gilt jedoch nicht für andere Frameworks.

Genau wie beim 10. Perzentil unterscheiden sich die Seiten auf Angular und React auch beim 90. Perzentil von anderen Seiten, aber sie unterscheiden sich leider zum Schlechten.

Beim 90. Perzentil senden Angular-Sites 141 % mehr Daten an Mobilgeräte als alle Sites und 159 % mehr an Desktops. React-Websites senden 73 % mehr an den Desktop als alle Websites und 58 % mehr an Mobilgeräte. Die Codegröße der React-Sites beim 90. Perzentil beträgt 2197.8 KB. Das bedeutet, dass diese Websites laut Vue 322.9 KB mehr Daten an mobile Geräte senden als ihre engsten Konkurrenten. Die Kluft zwischen Desktop-Sites, die auf Angular und React basieren, und anderen Sites ist sogar noch größer. Desktop-React-Sites senden beispielsweise 554.7 KB mehr JS-Code an Geräte als entsprechende Vue-Sites.

Zeit, die zum Verarbeiten des JavaScript-Codes im Hauptthread benötigt wird

Die oben genannten Daten zeigen deutlich, dass Websites, die die untersuchten Frameworks und Bibliotheken verwenden, große Mengen an JavaScript-Code enthalten. Aber das ist natürlich nur ein Teil unserer Gleichung.

Nachdem der JavaScript-Code im Browser angekommen ist, muss er in einen funktionsfähigen Zustand gebracht werden. Besonders viele Probleme werden durch die Aktionen verursacht, die mit dem Code im Hauptbrowser-Thread ausgeführt werden müssen. Der Hauptthread ist für die Verarbeitung von Benutzeraktionen, für die Berechnung von Stilen sowie für den Aufbau und die Anzeige des Seitenlayouts verantwortlich. Wenn Sie den Hauptthread mit JavaScript-Aufgaben überlasten, hat er nicht die Möglichkeit, die restlichen Aufgaben rechtzeitig abzuschließen. Dies führt zu Verzögerungen und „Bremsen“ in der Arbeit der Seiten.

Die HTTP-Archivdatenbank enthält Informationen darüber, wie lange es dauert, JavaScript-Code im Hauptthread der V8-Engine zu verarbeiten. Das bedeutet, dass wir diese Daten sammeln und herausfinden können, wie viel Zeit der Hauptthread benötigt, um das JavaScript verschiedener Websites zu verarbeiten.

Prozessorzeit (in Millisekunden) im Zusammenhang mit der Skriptverarbeitung auf Mobilgeräten

Perzentile
10
25
50
75
90

Alle Standorte
356.4
959.7
2372.1
5367.3
10485.8

jQuery-Sites
575.3
1147.4
2555.9
5511.0
10349.4

Vue-Sites
1130.0
2087.9
4100.4
7676.1
12849.4

Angular-Sites
1471.3
2380.1
4118.6
7450.8
13296.4

Reagieren Sie auf Websites
2700.1
5090.3
9287.6
14509.6
20813.3

Prozessorzeit im Zusammenhang mit der Skriptverarbeitung auf Mobilgeräten

Prozessorzeit (in Millisekunden) im Zusammenhang mit der Skriptverarbeitung auf Desktop-Geräten

Perzentile
10
25
50
75
90

Alle Standorte
146.0
351.8
831.0
1739.8
3236.8

jQuery-Sites
199.6
399.2
877.5
1779.9
3215.5

Vue-Sites
350.4
650.8
1280.7
2388.5
4010.8

Angular-Sites
482.2
777.9
1365.5
2400.6
4171.8

Reagieren Sie auf Websites
508.0
1045.6
2121.1
4235.1
7444.3

Prozessorzeit im Zusammenhang mit der Skriptverarbeitung auf Desktop-Geräten

Hier sieht man etwas sehr Bekanntes.

Zunächst einmal geben Websites mit jQuery deutlich weniger für die JavaScript-Verarbeitung im Hauptthread aus als andere Websites. Beim 10. Perzentil verbringen jQuery-Websites auf Mobilgeräten im Vergleich zu allen Websites 61 % mehr Zeit mit der Verarbeitung von JS-Code im Hauptthread. Bei Desktop-jQuery-Sites erhöht sich die Verarbeitungszeit um 37 %. Beim 90. Perzentil liegen jQuery-Sites sehr nahe an der Gesamtpunktzahl. Insbesondere verbringen jQuery-Sites auf Mobilgeräten 1.3 % weniger Zeit im Hauptthread als alle Sites und 0.7 % weniger Zeit auf Desktop-Geräten.

Auf der anderen Seite unserer Bewertung stehen die Frameworks, die sich durch die höchste Belastung des Hauptthreads auszeichnen. Dies ist wiederum Angular und React. Der einzige Unterschied zwischen den beiden besteht darin, dass Angular-Sites zwar mehr Code an Browser senden als React-Sites, Angular-Sites jedoch weniger CPU-Zeit für die Codeverarbeitung benötigen. Viel weniger.

Beim 10. Perzentil verbringen Desktop-Angular-Sites 230 % mehr Zeit mit der Verarbeitung von JS-Code im Hauptthread als alle Sites. Bei mobilen Websites liegt dieser Wert bei 313 %. Reaktionsseiten schneiden am schlechtesten ab. Auf dem Desktop verbringen sie 248 % mehr Zeit mit der Codeverarbeitung als auf allen Websites und 658 % mehr auf Mobilgeräten. 658 % ist kein Tippfehler. Beim 10. Perzentil verbringen React-Sites 2.7 Sekunden der Haupt-Thread-Zeit mit der Verarbeitung ihres Codes.

Das 90. Perzentil sieht im Vergleich zu diesen riesigen Zahlen zumindest etwas besser aus. Im Vergleich zu allen Websites verbringen Angular-Projekte 29 % mehr Zeit auf Desktop-Geräten im Hauptthread und 27 % mehr Zeit auf Mobilgeräten. Bei React-Sites liegen die gleichen Zahlen bei 130 % bzw. 98 %.

Prozentuale Abweichungen für das 90. Perzentil sehen besser aus als ähnliche Werte für das 10. Perzentil. Aber hier ist es erwähnenswert, dass die Zahlen, die die Zeit angeben, ziemlich beängstigend wirken. Nehmen wir an, 20.8 Sekunden im Haupt-Mobil-Thread für eine mit React erstellte Website. (Ich denke, die Geschichte darüber, was in dieser Zeit tatsächlich passiert, ist einen eigenen Artikel wert.)

Hier gibt es eine mögliche Komplikation (danke). Jeremia dass Sie mich auf diese Funktion aufmerksam gemacht und die Daten unter diesem Gesichtspunkt sorgfältig geprüft haben). Tatsache ist, dass viele Websites mehrere Front-End-Tools verwenden. Insbesondere habe ich viele Websites gesehen, die neben React oder Vue auch jQuery verwenden, da diese Websites von jQuery auf andere Frameworks oder Bibliotheken migrieren. Daraufhin habe ich erneut auf die Datenbank zugegriffen und dieses Mal nur die Links ausgewählt, die Websites entsprechen, die nur React, jQuery, Angular oder Vue, aber keine Kombination davon verwenden. Hier ist, was ich habe.

Prozessorzeit (in Millisekunden) im Zusammenhang mit der Verarbeitung von Skripten auf Mobilgeräten in einer Situation, in der Websites nur ein Framework oder nur eine Bibliothek verwenden

Perzentile
10
25
50
75
90

Websites, die nur jQuery verwenden
542.9
1062.2
2297.4
4769.7
8718.2

Websites, die nur Vue verwenden
944.0
1716.3
3194.7
5959.6
9843.8

Websites, die nur Angular verwenden
1328.9
2151.9
3695.3
6629.3
11607.7

Websites, die nur React verwenden
2443.2
4620.5
10061.4
17074.3
24956.3

Prozessorzeit im Zusammenhang mit der Verarbeitung von Skripten auf Mobilgeräten in einer Situation, in der Websites nur ein Framework oder nur eine Bibliothek verwenden

Erstens etwas, das nicht überraschend ist: Wenn eine Site nur ein Framework oder eine Bibliothek verwendet, verbessert sich die Leistung einer solchen Site in den meisten Fällen. Jedes Instrument schneidet im 10. und 25. Perzentil besser ab. Es ergibt Sinn. Eine Site, die mit einem Framework erstellt wurde, sollte eine bessere Leistung erbringen als eine Site, die mit zwei oder mehr Frameworks oder Bibliotheken erstellt wurde.

Tatsächlich sieht die Leistung jedes untersuchten Frontend-Tools bis auf eine merkwürdige Ausnahme in allen Fällen besser aus. Was mich überraschte, war, dass Websites, die React verwenden, ab dem 50. Perzentil schlechter abschneiden, wenn React die einzige Bibliothek ist, die sie verwenden. Dies war übrigens der Grund, warum ich diese Daten hier präsentiere.

Das ist etwas seltsam, aber ich werde trotzdem versuchen, nach einer Erklärung für diese Seltsamkeit zu suchen.

Wenn ein Projekt sowohl React als auch jQuery verwendet, befindet sich dieses Projekt wahrscheinlich irgendwo in der Mitte des Übergangs von jQuery zu React. Möglicherweise gibt es eine Codebasis, in der diese Bibliotheken gemischt sind. Da wir bereits gesehen haben, dass jQuery-Sites weniger Zeit mit dem Hauptthread verbringen als React-Sites, könnte uns dies darauf hinweisen, dass die Implementierung einiger Funktionen in jQuery zu einer etwas besseren Leistung der Site führt.

Aber während das Projekt von jQuery zu React übergeht und sich mehr auf React verlässt, ändern sich die Dinge. Wenn die Site wirklich hochwertig ist und die Site-Entwickler React sorgfältig verwenden, ist mit einer solchen Site alles in Ordnung. Für eine durchschnittliche React-Site bedeutet die intensive Nutzung von React jedoch, dass der Hauptthread stark ausgelastet ist.

Die Kluft zwischen mobilen und Desktop-Geräten

Ein weiterer Gesichtspunkt, aus dem ich die recherchierten Daten betrachtete, bestand darin, zu untersuchen, wie groß die Kluft zwischen der Arbeit mit Websites auf mobilen und Desktop-Geräten ist. Wenn wir über den Vergleich der Mengen an JavaScript-Code sprechen, dann zeigt ein solcher Vergleich nichts Schlimmes. Natürlich wäre es schön, kleinere Mengen an herunterladbarem Code zu sehen, aber es gibt keinen großen Unterschied in der Menge an Mobil- und Desktop-Code.

Wenn wir jedoch die Zeit analysieren, die für die Verarbeitung des Codes erforderlich ist, fällt eine sehr große Lücke zwischen mobilen und Desktop-Geräten auf.

Zeitzuwachs (Prozentsatz) im Zusammenhang mit der Verarbeitung von Skripten auf mobilen Geräten im Vergleich zum Desktop

Perzentile
10
25
50
75
90

Alle Standorte
144.1
172.8
185.5
208.5
224.0

jQuery-Sites
188.2
187.4
191.3
209.6
221.9

Vue-Sites
222.5
220.8
220.2
221.4
220.4

Angular-Sites
205.1
206.0
201.6
210.4
218.7

Reagieren Sie auf Websites
431.5
386.8
337.9
242.6
179.6

Obwohl ein gewisser Unterschied in der Codeverarbeitungsgeschwindigkeit zwischen einem Telefon und einem Laptop zu erwarten ist, sagen mir diese großen Zahlen, dass moderne Frameworks nicht ausreichend auf Geräte mit geringer Leistung ausgerichtet sind und dass sie bestrebt sind, die entdeckte Lücke zu schließen. Selbst beim 10. Perzentil verbringen React-Sites 431.5 % mehr Zeit im mobilen Hauptthread als im Desktop-Hauptthread. Den geringsten Abstand weist jQuery auf, aber auch hier liegt der entsprechende Wert bei 188.2 %. Wenn Website-Entwickler ihre Projekte so gestalten, dass ihre Verarbeitung mehr Prozessorzeit erfordert (und das passiert, und es wird mit der Zeit nur noch schlimmer), müssen Besitzer von Geräten mit geringer Leistung dafür bezahlen.

Ergebnisse

Gute Frameworks sollten Entwicklern eine gute Grundlage für die Erstellung von Webprojekten bieten (hinsichtlich Sicherheit, Zugänglichkeit, Leistung), oder sie sollten über eingebaute Einschränkungen verfügen, die es schwierig machen, etwas zu erstellen, das gegen diese Einschränkungen verstößt.

Dies scheint nicht auf die Leistung von Webprojekten zuzutreffen (und vermutlich auch nicht auf deren Leistung). Verfügbarkeit).

Es ist erwähnenswert, dass die Tatsache, dass React- oder Angular-Sites mehr CPU-Zeit für die Codevorbereitung aufwenden als andere, nicht zwangsläufig bedeutet, dass React-Sites während der Ausführung CPU-intensiver sind als Vue-Sites. Tatsächlich sagen die von uns überprüften Daten sehr wenig über die betriebliche Leistung von Frameworks und Bibliotheken aus. Sie sprechen mehr über die Entwicklungsansätze, die diese Frameworks, bewusst oder unbewusst, Programmierer vorantreiben können. Wir sprechen über Dokumentation für Frameworks, über deren Ökosystem, über gängige Entwicklungstechniken.

Erwähnenswert ist auch etwas, das wir hier nicht analysiert haben, nämlich wie viel Zeit das Gerät mit der Ausführung von JavaScript-Code verbringt, wenn es zwischen den Seiten der Website navigiert. Das Argument für SPA ist, dass der Benutzer die Seiten der Website theoretisch schneller öffnen kann, sobald die Single-Page-Anwendung in den Browser geladen ist. Meine eigene Erfahrung zeigt mir, dass dies alles andere als eine Tatsache ist. Aber wir haben keine Daten, um dieses Problem zu klären.

Es ist klar, dass Sie, wenn Sie ein Framework oder eine Bibliothek zum Erstellen einer Website verwenden, einen Kompromiss eingehen, indem Sie das Projekt zunächst laden und betriebsbereit machen. Dies gilt selbst für die positivsten Szenarien.

Es ist durchaus möglich, in geeigneten Situationen einige Kompromisse einzugehen, aber es ist wichtig, dass Entwickler solche Kompromisse bewusst eingehen.

Aber wir haben auch Grund zum Optimismus. Ich bin gespannt, wie eng die Chrome-Entwickler mit den Entwicklern einiger der von uns überprüften Front-End-Tools zusammenarbeiten, um die Leistung dieser Tools zu verbessern.

Allerdings bin ich ein pragmatischer Mensch. Neue Architekturen verursachen Leistungsprobleme genauso oft, wie sie diese lösen. Und es braucht Zeit, Fehler zu beheben. So wie wir es nicht erwarten sollten neue Netzwerktechnologien wird alle Leistungsprobleme lösen, das sollten Sie von neuen Versionen unserer Lieblings-Frameworks nicht erwarten.

Wenn Sie eines der in diesem Artikel besprochenen Frontend-Tools verwenden möchten, bedeutet dies, dass Sie zusätzliche Anstrengungen unternehmen müssen, um die Leistung Ihres Projekts in der Zwischenzeit nicht zu beeinträchtigen. Hier sind einige Überlegungen, die Sie berücksichtigen sollten, bevor Sie mit einem neuen Framework beginnen:

• Testen Sie sich selbst mit gesundem Menschenverstand. Ist es wirklich notwendig, das gewählte Framework zu verwenden? Reines JavaScript kann heute viel.
• Gibt es eine leichtere Alternative zum gewählten Framework (wie Preact, Svelte oder etwas anderes), die Ihnen 90 % der Funktionen dieses Frameworks bietet?
• Wenn Sie bereits ein Framework verwenden, überlegen Sie, ob es etwas gibt, das bessere, konservativere Standardoptionen bietet (z. B. Nuxt.js anstelle von Vue, Next.js anstelle von React usw.).
• Was wird Ihr Budget JavaScript-Leistung?
• Wie kannst du einschränken ein Entwicklungsprozess, der es schwieriger macht, mehr JavaScript-Code in ein Projekt einzuschleusen als unbedingt nötig?
• Wenn Sie zur Vereinfachung der Entwicklung ein Framework verwenden, sollten Sie darüber nachdenken brauchst du Rahmencode an Kunden senden. Vielleicht können Sie alle Probleme auf dem Server lösen?

In der Regel sind diese Ideen einen Blick wert, unabhängig davon, wofür Sie sich genau für die Frontend-Entwicklung entschieden haben. Sie sind jedoch besonders wichtig, wenn Sie an einem Projekt arbeiten, bei dem es von Anfang an an Leistung mangelt.

Liebe Leser! Wie sehen Sie das ideale JavaScript-Framework?

Source: habr.com