🤜 🕵🏿 ⭐️ Der Preis für JavaScript-Frameworks 📭 🗾 🐡

Es gibt keinen schnelleren Weg, eine Site zu verlangsamen (wie ein Wortspiel), als eine Menge JavaScript-Code darauf zu verwenden. Wenn Sie JavaScript verwenden, müssen Sie dafür mindestens viermal mit Projektleistung bezahlen. So lädt der JavaScript-Code der Site Benutzersysteme:

Laden Sie eine Datei über das Netzwerk herunter.
Analysieren und Kompilieren von entpacktem Quellcode nach dem Laden.
Ausführung von JavaScript-Code.
Speicherverbrauch.

Diese Kombination ist sehr teuer . Und wir nehmen immer mehr JS-Code in unsere Projekte auf. Wenn Unternehmen auf Websites umsteigen, die auf Frameworks und Bibliotheken wie React, Vue und anderen basieren, machen wir die Kernfunktionalität von Websites stark von JavaScript abhängig.

Ich habe viele sehr schwere Websites mit JavaScript-Frameworks gesehen. Aber meine Vision des Themas ist sehr voreingenommen. Tatsache ist, dass die Unternehmen, mit denen ich zusammenarbeite, mich genau deshalb kontaktieren, weil sie auf komplexe Probleme im Bereich der Website-Leistung stoßen. Infolgedessen wurde ich neugierig, wie weit verbreitet dieses Problem ist und welche Art von „Geldstrafen“ wir zahlen, wenn wir das eine oder andere Framework als Grundlage für eine bestimmte Site auswählen.

Das HTTP-Archivprojekt hat mir dabei geholfen, dies herauszufinden .

Daten

Insgesamt verfolgt das HTTP-Archivprojekt 4.308.655 Links zu regulären Websites für Desktop-Geräte und 5.484.239 Links zu mobilen Websites. Unter den vielen mit diesen Links verbundenen Indikatoren befindet sich eine Liste der Technologien, die auf den jeweiligen Websites zu finden sind. Dies bedeutet, dass wir eine Stichprobe von Tausenden von Websites erstellen können, die verschiedene Frameworks und Bibliotheken verwenden, und herausfinden können, wie viel Code sie an Kunden senden und wie viel Last die Benutzersysteme diesen Code erstellen.

Ich habe Daten für März 2020 gesammelt. Dies waren die neuesten Daten, auf die ich Zugriff hatte.

Ich habe beschlossen, aggregierte HTTP-Archivdaten für alle Sites mit Daten für Sites zu vergleichen, bei denen React, Vue und Angular erkannt wurden, obwohl ich überlegte, anderes Quellmaterial zu verwenden.

Um es interessanter zu machen, habe ich dem Quelldatensatz auch Websites hinzugefügt, die jQuery verwenden. Diese Bibliothek ist immer noch sehr beliebt. Es bietet auch einen Website-Entwicklungsansatz, der sich von dem von React, Vue und Angular vorgeschlagenen SPA-Modell (Single Page Application) unterscheidet.

Links im HTTP-Archiv, die Websites darstellen, die den Einsatz von Technologien entdeckt haben, die für uns von Interesse sind

Framework oder Bibliothek	Links zu mobilen Websites	Links zu regulären Websites
jQuery	4615474	3714643
Reagieren	489827	241023
Vue	85649	43691
Winkelig	19423	18088

Hoffnungen und Träume

Bevor wir zur Datenanalyse übergehen, möchte ich darüber sprechen, worauf ich hoffen möchte.

Ich bin der Meinung, dass in einer idealen Welt Frameworks über die Befriedigung der Bedürfnisse von Entwicklern hinausgehen und normalen Benutzern, die mit unseren Websites arbeiten, bestimmte konkrete Vorteile bieten sollten. Leistung ist nur einer dieser Vorteile. Hier kommen Zugänglichkeit und Sicherheit noch in den Sinn. Dies ist jedoch nur das Wichtigste.

In einer idealen Welt sollte ein bestimmter Rahmen die Erstellung einer Hochleistungssite erleichtern. Dies sollte entweder aufgrund der Tatsache geschehen, dass das Framework dem Entwickler eine anständige Grundlage für die Erstellung des Projekts bietet, oder aufgrund der Tatsache, dass es Einschränkungen für die Entwicklung auferlegt, Anforderungen dafür stellt, die die Entwicklung von etwas erschweren, das sich als langsam herausstellt.

Die besten Rahmenbedingungen sollten beides tun: eine gute Basis bieten und die Arbeit einschränken, um ein anständiges Ergebnis zu erzielen.

Die Analyse der mittleren Datenwerte liefert nicht die erforderlichen Informationen. Tatsächlich lässt ein solcher Ansatz viel Wichtiges außerhalb unserer Aufmerksamkeit . Stattdessen habe ich aus meinen Daten Indikatoren in Perzentilen abgeleitet. Dies sind 10, 25, 50 (Median), 75, 90 Perzentile.

Ich interessiere mich besonders für das 10. und 90. Perzentil. Das 10. Perzentil repräsentiert die beste Leistung (oder zumindest mehr oder weniger nahe an der besten) für ein bestimmtes Framework. Mit anderen Worten bedeutet dies, dass nur 10% der Websites, die ein bestimmtes Framework verwenden, dies erreichen oder auf ein höheres Niveau. Das 90. Perzentil hingegen ist die Kehrseite der Medaille - es zeigt uns, wie schlimm die Dinge sein können. Das 90. Perzentil sind die Web-Sites - die letzten 10% der Sites, die durch das größte Volumen an JS-Code oder die längste Zeit gekennzeichnet sind, die für die Verarbeitung ihres Codes im Hauptstrom erforderlich ist.

JavaScript-Code-Volumes

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

Die Menge an JavaScript-Code (Kb), die auf mobile Geräte übertragen wird

	10	25	50	75	90
	93.4	196.6	413.5	746.8	1201.6
jQuery-	110.3	219.8	430.4	748.6	1162.3
Vue-	244.7	409.3	692.1	1065.5	1570.7
Angular-	445.1	675.6	1066.4	1761.5	2893.2
React-	345.8	441.6	690.3	1238.5	1893.6

JavaScript-,

JavaScript- (),

	10	25	50	75	90
	105.5	226.6	450.4	808.8	1267.3
jQuery-	121.7	242.2	458.3	803.4	1235.3
Vue-	248.0	420.1	718.0	1122.5	1643.1
Angular-	468.8	716.9	1144.2	1930.0	3283.1
React-	308.6	469.0	841.9	1472.2	2197.8

Die Menge an JavaScript-Code, die an Desktop-Geräte übertragen wird

Wenn wir nur über die Größe des JS-Codes sprechen, der von Websites an Geräte gesendet wird, sieht alles so aus, wie Sie es erwarten würden. Wenn eines der Frameworks verwendet wird, bedeutet dies, dass selbst im Idealfall das Volumen des JavaScript-Codes der Site zunimmt. Dies ist nicht überraschend - Sie können das JavaScript-Framework nicht zur Basis der Site machen und erwarten, dass das Volumen des JS-Codes des Projekts sehr gering sein wird.

In diesen Daten ist bemerkenswert, dass einige Frameworks und Bibliotheken als erfolgreicherer Ausgangspunkt des Projekts angesehen werden können als andere. JQuery-Sites sehen am besten aus. Auf Desktop-Versionen von Websites enthalten sie 15% mehr JavaScript als alle Websites und auf mobilen Versionen 18% mehr. (Ich muss zugeben, dass Sie hier eine gewisse Verzerrung der Daten beobachten können. Tatsache ist, dass jQuery auf vielen Websites vorhanden ist. Daher ist es natürlich, dass solche Websites näher an der Gesamtzahl der Websites liegen als andere. Dies hat jedoch keinen Einfluss auf die Art und Weise Quelldaten werden für jedes Framework angezeigt.)

Obwohl eine Erhöhung des Codes um 15 bis 18% im Vergleich zu anderen Frameworks und Bibliotheken eine signifikante Zahl darstellt, können wir den Schluss ziehen, dass die von jQuery erhobene „Steuer“ sehr niedrig ist. Websites im Winkel des 10. Perzentils senden 344% mehr Daten an Desktop-Geräte als alle Websites und an Mobiltelefone - 377% mehr. React Sites, die nächsten in Bezug auf den Schweregrad, senden 193% mehr Code an Desktop-Geräte als alle Sites und 270% mehr an mobile Geräte.

Ich habe bereits erwähnt, dass, obwohl die Verwendung des Frameworks bedeutet, dass eine bestimmte Menge an Code in das Projekt aufgenommen wird, ich hoffe, dass das Framework den Entwickler zu Beginn der Arbeit irgendwie einschränken kann. Insbesondere geht es darum, die maximale Codemenge zu begrenzen.

Interessanterweise folgen jQuery-Sites dieser Idee. Obwohl sie auf der Ebene des 10. Perzentils etwas schwerer sind als alle Websites (15 bis 18%), sind sie auf der Ebene des 90. Perzentils etwas leichter als alle anderen - sowohl in Desktop- als auch in Mobilversionen um etwa 3%. Dies kann nicht als sehr bedeutender Vorteil bezeichnet werden, aber es kann gesagt werden, dass sich jQuery-Sites zumindest in ihren größten Versionen nicht in der Größe des JavaScript-Codes unterscheiden.

Das Gleiche gilt jedoch nicht für andere Frameworks.

Wie beim 10. Perzentil unterscheiden sich die 90. Perzentilstellen auf Angular und React von anderen Stellen, aber leider unterscheiden sie sich zum Schlechten.

Beim 90. Perzentil senden Angular-Sites 141% mehr Daten an mobile Geräte als alle Sites und 159% mehr an den Desktop. React-Sites senden 73% mehr an Desktop-Geräte als alle Sites und 58% mehr an Mobilgeräte. Die Codegröße der React-Sites im 90. Perzentil beträgt 2197,8 KB. Dies bedeutet, dass solche Websites 322,9 KB mehr Daten an mobile Geräte senden als ihre engsten Konkurrenten basierend auf Vue. Die Lücke zwischen den auf Angular und React basierenden Desktop-Sites und zwischen anderen Sites ist noch größer. Beispielsweise senden Desktop-React-Sites 554,7 KB mehr JS-Code an Geräte als ähnliche Vue-Sites.

Zeitaufwand für die Verarbeitung von JavaScript-Code im Hauptthread

Die obigen 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 funktionierenden Zustand versetzt werden. Besonders viele Probleme verursachen die Aktionen, die mit dem Code im Hauptstrom des Browsers ausgeführt werden müssen. Der Hauptthread ist für die Verarbeitung von Benutzeraktionen, die Berechnung von Stilen sowie für die Erstellung und Anzeige des Seitenlayouts verantwortlich. Wenn Sie den Hauptstrom mit JavaScript-Angelegenheiten füllen, kann er andere Aufgaben nicht rechtzeitig lösen. Dies führt zu Verzögerungen und "Bremsen" bei der Arbeit der Seiten.

Die HTTP-Archivdatenbank enthält Informationen darüber, wie viel Zeit für die Verarbeitung von JavaScript-Code im Hauptthread der V8-Engine erforderlich ist. Dies bedeutet, dass wir diese Daten sammeln und herausfinden können, wie viel Zeit der Hauptthread benötigt, um das JavaScript verschiedener Websites zu verarbeiten.

CPU-Zeit (in Millisekunden) im Zusammenhang mit der Skriptverarbeitung auf Mobilgeräten

Perzentile	10	25	fünfzig	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
Winkelstellen	1471.3	2380.1	4118.6	7450.8	13296.4
Websites reagieren	2700.1	5090.3	9287.6	14509.6	20813.3

CPU-Zeit für die Skriptverarbeitung auf Mobilgeräten

CPU-Zeit (in Millisekunden) für die Skriptverarbeitung auf Desktop-Geräten

Perzentile	10	25	fünfzig	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-	350.4	650.8	1280.7	2388.5	4010.8
Angular-	482.2	777.9	1365.5	2400.6	4171.8
React-	508.0	1045.6	2121.1	4235.1	7444.3

CPU-Zeit im Zusammenhang mit der Verarbeitung von Skripten auf Desktop-Geräten

Hier sehen Sie etwas sehr Vertrautes.

Für den Anfang geben Websites mit jQuery deutlich weniger für die JavaScript-Verarbeitung im Hauptthread aus als andere. Beim 10. Perzentil verbringen jQuery-Sites auf Mobilgeräten im Vergleich zu allen Sites 61% mehr Zeit mit der Verarbeitung von JS-Code im Hauptthread. Bei Desktop-jQuery-Sites wird die Verarbeitungszeit um 37% erhöht. Auf der 90. Perzentilebene liegen die jQuery-Site-Metriken sehr nahe an den aggregierten Metriken. JQuery-Sites auf Mobilgeräten verbringen nämlich 1,3% weniger Zeit im Hauptstrom als alle Sites und auf Desktop-Geräten - 0,7% weniger Zeit.

Auf der anderen Seite unserer Bewertung gibt es Frameworks, die sich durch die größte Belastung des Hauptfadens auszeichnen. Dies ist wiederum Angular and React. Der einzige Unterschied besteht darin, dass Angular-Sites zwar größere Codemengen an Browser senden als React-Sites, die Verarbeitung des Codes von Angular-Sites jedoch weniger Prozessorzeit benötigt. Viel weniger.

Beim 10. Perzentil verbringen Desktop-Angular-Sites 230% mehr Zeit mit der Verarbeitung von JS-Code im Hauptthread als alle Sites. Für mobile Websites beträgt diese Zahl 313%. Reaktionsstellen weisen die schlechteste Leistung auf. Auf Desktop-Geräten verbringen sie 248% mehr Zeit mit der Codeverarbeitung als auf allen Websites und auf Mobilgeräten - 658% mehr. 658% ist kein Tippfehler. Beim 10. Perzentil verbringen React-Sites 2,7 Sekunden der Haupt-Thread-Zeit damit, den vorhandenen Code zu verarbeiten.

Das 90. Perzentil sieht im Vergleich zu diesen riesigen Zahlen zumindest etwas besser aus. Angular-Projekte verbringen im Vergleich zu allen Websites 29% mehr Zeit mit Desktop-Geräten im Hauptthread und 27% mehr Zeit mit Mobilgeräten. Bei React-Standorten liegen ähnliche Indikatoren 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 daran zu erinnern, dass die Zahlen, die die Zeit anzeigen, ziemlich beängstigend erscheinen. Sagen wir - 20,8 Sekunden im Hauptstrom eines Mobilgeräts für eine Site, die auf React basiert. (Ich glaube, dass die Geschichte von dem, was in dieser Zeit tatsächlich passiert, einen separaten Artikel verdient).

Es gibt eine mögliche Schwierigkeit (dankeJeremy, weil er mich auf diese Funktion aufmerksam gemacht und die Daten unter diesem Gesichtspunkt sorgfältig geprüft hat). Tatsache ist, dass viele Websites mehrere Front-End-Tools verwenden. Insbesondere habe ich viele Websites gesehen, die jQuery zusammen mit React oder Vue verwenden, da diese Websites von jQuery zu anderen Frameworks oder Bibliotheken migrieren. Infolgedessen habe ich mich erneut der Datenbank zugewandt und diesmal nur die Links ausgewählt, die Websites entsprechen, die nur React, jQuery, Angular oder Vue verwenden, aber keine Kombination davon. Das ist, was ich tat.

Die CPU-Zeit (in Millisekunden) bezieht sich auf die Verarbeitung von Skripten auf Mobilgeräten in einer Situation, in der Sites nur ein Framework oder nur eine Bibliothek verwenden

Perzentile	10	25	fünfzig	75	90
, jQuery	542.9	1062.2	2297.4	4769.7	8718.2
, Vue	944.0	1716.3	3194.7	5959.6	9843.8
, Angular	1328.9	2151.9	3695.3	6629.3	11607.7
, React	2443.2	4620.5	10061.4	17074.3	24956.3

CPU-Zeit im Zusammenhang mit der Verarbeitung von Skripten auf Mobilgeräten in einer Situation, in der nur ein Framework an Standorten oder nur eine Bibliothek verwendet wird

Zunächst ist es nicht überraschend: Wenn nur ein Framework oder eine Bibliothek an einem Standort verwendet wird, ist die Leistung eines solchen Standorts häufiger verbessern als nicht verbessern. Die Indikatoren für jedes Instrument sehen bei 10 und 25 Perzentilen besser aus. Es ergibt Sinn. Eine Site, die mit einem Framework erstellt wird, sollte produktiver sein als eine Site, die mit zwei oder mehr Frameworks oder Bibliotheken erstellt wird.

Tatsächlich sehen die Indikatoren für jedes untersuchte Front-End-Instrument in allen Fällen besser aus, abzüglich einer merkwürdigen Ausnahme. Ich war überrascht, dass Websites mit React ab dem 50. Perzentil eine schlechtere Leistung aufweisen, wenn React die einzige Bibliothek ist, die auf ihnen verwendet wird. Dies war übrigens der Grund, warum ich diese Daten hierher bringe.

Das ist ein bisschen seltsam, aber ich versuche immer noch, nach einer Erklärung für diese Kuriosität zu suchen.

Wenn ein Projekt sowohl React als auch jQuery verwendet, befindet sich dieses Projekt höchstwahrscheinlich in der Mitte des Übergangs von jQuery zu React. Vielleicht hat es eine Codebasis, in der diese Bibliotheken gemischt sind. Da wir bereits festgestellt haben, dass jQuery-Sites weniger Zeit im Hauptthread verbringen als React-Sites, kann dies darauf hinweisen, dass die Implementierung einiger Funktionen in jQuery dazu beiträgt, die Leistung der Site geringfügig zu verbessern.

Da sich das Projekt, das von jQuery zu React wechselt, mehr auf React stützt, ändert sich die Situation. Wenn die Site von wirklich hoher Qualität ist und die Entwickler der Site React umsichtig verwenden, ist mit dieser Site alles in Ordnung. Für die durchschnittliche React-Site bedeutet die weit verbreitete Verwendung von React jedoch, dass der Haupt-Thread einer erhöhten Last ausgesetzt ist.

Die Lücke zwischen Mobil- und Desktopgeräten

Ein weiterer Gesichtspunkt, von dem aus ich die untersuchten Daten betrachtete, war die Untersuchung, wie groß die Lücke zwischen der Arbeit mit Websites auf Mobil- und Desktopgeräten ist. Wenn wir über den Vergleich der Volumina von JavaScript-Code sprechen, zeigt ein solcher Vergleich nichts Schreckliches. Natürlich wäre es schön, kleinere Mengen heruntergeladenen Codes zu sehen, aber es gibt keinen großen Unterschied in der Menge an mobilem und Desktop-Code.

Wenn Sie jedoch die für die Verarbeitung des Codes erforderliche Zeit analysieren, werden Sie eine sehr große Lücke zwischen Mobil- und Desktopgeräten feststellen.

Der Zeitanstieg (in Prozent) bezog sich auf die Verarbeitung von Skripten auf Mobilgeräten im Vergleich zum Desktop

Perzentile	10	25	fünfzig	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
Winkelstellen	205.1	206.0	201.6	210.4	218.7
Websites reagieren	431.5	386.8	337.9	242.6	179,6

Obwohl ein gewisser Unterschied in der Verarbeitungsgeschwindigkeit des Codes zwischen Telefon und Laptop zu erwarten ist, sagen mir so viele, dass moderne Frameworks sich nicht ausreichend auf Geräte mit geringem Stromverbrauch und auf den Wunsch konzentrieren, die Lücke zu schließen. Selbst beim 10. Perzentil verbringen React-Sites 431,5% mehr Zeit im Hauptstrom mobiler Geräte als im Hauptstrom von Desktopgeräten. Die kleinste Lücke wird in jQuery beobachtet, aber auch hier liegt der entsprechende Indikator bei 188,2%. Wenn Website-Entwickler ihre Projekte so gestalten, dass mehr Prozessorzeit für die Verarbeitung benötigt wird (und dies geschieht, und mit der Zeit wird alles schlimmer), müssen Besitzer von Geräten mit geringem Stromverbrauch dafür bezahlen.

Zusammenfassung

Gute Frameworks sollten Entwicklern eine qualitativ hochwertige Basis für die Erstellung von Webprojekten bieten (in Bezug auf Sicherheit, Zugänglichkeit, Leistung) oder integrierte Einschränkungen aufweisen, die es schwierig machen, etwas zu erstellen, das gegen diese Einschränkungen verstößt.

Dies scheint nicht für die Leistung von Webprojekten (und anscheinend für deren Verfügbarkeit ) zu gelten.

Es ist erwähnenswert, dass die Tatsache, dass React- oder Angular-Sites mehr CPU-Zeit für die Codevorbereitung aufwenden als andere, nicht unbedingt bedeutet, dass React-Sites im Laufe der Arbeit den Prozessor mehr als Vue-Sites laden. Tatsächlich sagen die von uns überprüften Daten nur sehr wenig über die Leistung von Frameworks und Bibliotheken aus. Sie sprechen mehr über Entwicklungsansätze, zu denen diese Frameworks Programmierer bewusst oder unbewusst antreiben können. Wir sprechen über die Dokumentation von Frameworks, über deren Ökosystem und über gemeinsame Entwicklungstechniken.

Es ist erwähnenswert, dass wir es hier nicht analysiert haben, nämlich wie viel Zeit das Gerät für die Ausführung von JavaScript-Code beim Navigieren zwischen Seiten der Website benötigt. Das Argument für SPA ist, dass der Benutzer theoretisch die Seiten der Site schneller öffnen kann, sobald eine einseitige Anwendung in den Browser geladen wird. Meine eigene Erfahrung zeigt mir, dass dies alles andere als eine Tatsache ist. Wir haben jedoch keine Daten, um dieses Problem zu klären.

Es ist nur klar, dass Sie beim Erstellen einer Site durch ein Framework oder eine Bibliothek Kompromisse beim erstmaligen Laden des Projekts und bei der Vorbereitung auf die Arbeit eingehen. Dies gilt auch für die positivsten Szenarien.

In geeigneten Situationen ist es durchaus möglich, Kompromisse einzugehen, aber es ist wichtig, dass die Entwickler bewusste Kompromisse eingehen.

Wir haben aber Grund, optimistisch zu sein. Ich bin ermutigt darüber, wie eng Chrome-Entwickler mit einigen der von uns überprüften Front-End-Tools zusammenarbeiten, um die Leistung dieser Tools zu verbessern.

Ich bin jedoch eine pragmatische Person. Neue Architekturen verursachen so oft Leistungsprobleme wie sie lösen. Und es braucht Zeit, um die Fehler zu beheben. So wie wir nicht erwarten sollten, dass neue Netzwerktechnologien alle Leistungsprobleme lösen, sollten wir dies auch nicht von neuen Versionen unserer bevorzugten Frameworks erwarten.

Wenn Sie eines der in diesem Material beschriebenen Front-End-Tools verwenden möchten, müssen Sie zusätzliche Anstrengungen unternehmen, um sicherzustellen, dass die Produktivität Ihres Projekts in der Zwischenzeit nicht beeinträchtigt wird. Hier sind einige Überlegungen zu beachten, bevor Sie mit der Verwendung des neuen Frameworks beginnen:

Testen Sie sich mit gesundem Menschenverstand. Müssen Sie das gewählte Framework wirklich verwenden? Reines JavaScript kann heute viel.
Gibt es eine einfachere Alternative zum gewählten Framework (wie Preact, Svelte oder etwas anderes), mit der Sie 90% der Funktionen dieses Frameworks nutzen können?
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 JavaScript - Performance Budget ?
Wie können Sie den Entwicklungsprozess einschränken, um die Implementierung einer größeren Menge von JavaScript-Code in das Projekt zu erschweren, als unbedingt erforderlich ist?
Wenn Sie das Framework zur Vereinfachung der Entwicklung verwenden, prüfen Sie , ob Sie den Framework-Code an Ihre Clients senden müssen . Vielleicht können Sie alle Probleme auf dem Server lösen?

Normalerweise sind diese Ideen einen Blick wert, unabhängig davon, was genau Sie für die Entwicklung des Frontends ausgewählt haben. Sie sind jedoch besonders wichtig, wenn Sie an einem Projekt arbeiten, bei dem es von Anfang an an Produktivität mangelt.

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