Brechen - nicht bauen. Oder Devolution

Kürzlich erschienen einige interessante Artikel über Habré. Der erste befasste sich mit dem ES6-Minimierungsproblem , der zweite mit allgemeinen nützlichen Tipps zur Optimierung von Webpacks .

Alles wäre in Ordnung, aber beide haben das Problem der Aufteilung von Bundles in ES6 und ES5 zur Minimierung und für andere Optimierungszwecke umgangen. Und im Allgemeinen, während einige Artikel darüber schreiben und schreiben, ignorieren andere (fast alle) diese Technik.

Weil für eine lange Zeit. Teuer Und nicht so sehr.

Aber es ist schnell, billig und dümmer notwendig. Vielleicht sollten Sie die Evolution einfach umkehren.

Idee

Eine „Idee“ zu beschreiben ist keine gute Idee. Es ist besser zu beschreiben, wie es funktionieren soll. Wie der Bündelbildungsprozess funktionieren sollte:

• Ich habe einen Code
• Ich kompiliere es unter meinem "Entwicklungs" -Browser
• und alles funktioniert.

Der Entwicklungsbrowser ist hier, damit Async / Warten, Generator, Klassen, Pfeilfunktionen und so weiter. Im Allgemeinen Ziel: Esmodule im Babel.

Ich weiß nichts über dich, aber ich mag diese Idee. Hier sind nur die alten Browser, die noch unter uns sind, diese Idee passt nicht so. (und deshalb zischen wir alle es5 in der Produktion und würzen mit einem halben Megabyte Polyfills)

Und genau das muss behoben werden.

Devolution

Devolution ist ein kleines CLI-Dienstprogramm, das Ihr in target: esmodules kompiliertes Bundle in es5 zerlegt und dabei alle erforderlichen Polydateien hinzufügt.

Kurz gesagt:

• Alle JS-Skripte sind
• Führen Sie babel mit einem aktiven Plugin (fork useBuiltins: "usage") durch, das die erforderlichen Polydateien definiert. Dies ist schnell, da es keine Transformationen gibt.
• Für jede Datei werden alle benötigten Polyphile gesammelt (abzüglich der bereits im Hauptpaket enthaltenen), zusammengeführt, durch den Terser geführt und am Anfang der Datei hinzugefügt.
• Jede Datei wird über swc ausgeführt, eine Rostversion von babel, mit der der Code auf ein Niveau aktualisiert wird, das IE11 versteht. Funktioniert 10-60 mal schneller als babel. Es werden keine verschiedenen Plugins unterstützt, dies ist jedoch nicht erforderlich. Es wird lediglich __ bereits__ angewendet.
• terser wird dem Ergebnis erneut überlagert, jedoch mit deaktivierter Mangel (Namenskomprimierung), was wiederum schnell ist.
• All dies geschieht bei den Arbeitern.

Ich habe den Code für drei Projekte mit unterschiedlichen Schwierigkeitsgraden ausgeführt:

• Projekt 1, 60 endgültige JS-Dateien (Code-Splitting). Bauzeit 400s. Devolution 30s.
• Projekt 2, 1 endgültige JS-Datei (30 MB). Bauzeit 120s. Devolution 10s.
• Projekt 3, 1 endgültige JS-Datei (2 MB). Bauzeit 20s. Devolution 5s (zu Beginn der Arbeiter gehen viele Dinge verloren).

Der Bonus aus dem ESM-Bundle war etwas seltsam:

• Ein Projekt verlor 400 KB Babel / Polyfill. Es wurden dort keine "über" Browser-Chips verwendet, und in "esm" müssen sie nicht poliert werden
• Ein Projekt verlor 10% aufgrund des viel kompakteren Codes von Generatoren, Async / Warten und Klassenkonstruktoren
• Ein Projekt ist dicker geworden, da „lose“ Babel-Transformationen den Code manchmal kompakter machen. Der lose Modus ist jedoch eine etwas gefährliche Option, während der Code „ES6“ „sicher“ ist.

Noch einmal:

• wir nehmen ES6-Code (genauer gesagt esmodule, let / const wird aus Geschwindigkeitsgründen durch var ersetzt)
• mach daraus ES5
• auf die Seite von Polyphilen werfen
• Streue auf Papas, füge Symlinks zu anderen Dateien hinzu
• Wir ändern die Verbindung von Skripten zu Seiten etwas intelligenter (IE11-Module / Nomodule verstehen nicht)
• erledigt - ESM für 85% der benutzerdefinierten Zähler, ES5 für diejenigen im Tank.

Einfach. Schnell. Einfach nur dumm. Wir haben das Bundle de-aktualisiert. Alte Browser! Au - serviert.

Nun, neue Browser erhalten ein Bundle mit fast keinen Polyfills, ohne schreckliche Transformationen von Generatoren und Async / Warten, mit Pfeilfunktionen ohne Tamburine (und sie sind im Allgemeinen schneller). Im Allgemeinen sind alle glücklich, es scheint, dass dies ursprünglich beabsichtigt war.

github.com/thekashey/devolution

PS: Derzeit verwendet devolution swc nicht , da der Code manchmal nicht sehr gut funktioniert - github.com/swc-project/swc/issues/280 , Babel ist nicht so viel langsamer -, wo swc korrigiert wurde In 20 Sekunden schafft es Babel in einer Minute. Bei einer „normalen“ Bauzeit - ab 5 - ist dies ein großes Plus

PS: Wenn es plötzlich interessant wurde, warum Devolution - das Video ist hier .