esbuild, Teil 1: JavaScript-Bundling leicht gemacht
Seite 2: Transpiler-Historie
Die ersten Transpiler wie Browserify kamen vor etwa zehn Jahren auf – geboren aus dem Wunsch, JavaScript-Code sowohl in Node.js als auch im Browser zu verwenden. Da dort zu dieser Zeit noch keine Möglichkeit bestand, Abhängigkeiten zwischen Modulen und exportierten Objekten aufzulösen, ließen sich npm-Module nicht ohne weiteres im Browser wiederverwenden. Transpiler sollten also Node.js-JavaScript-Code für Browser umschreiben, zu einer oder mehreren größeren JavaScript-Dateien verdichten und Modulabhängigkeiten auflösen.
Mit dem Aufkommen von React und dessen JSX-Erweiterung entstand die Notwendigkeit, daraus wieder regulären, von der JavaScript-Engine direkt ausführbaren Vanilla-JavaScript-Code zu erzeugen.
Ein auch heute noch als Platzhirsch geltender JavaScript-Transpiler ist Babel. Er lässt sich über Plug-ins sogar derart erweitern, dass in der Folge selbst proprietäre JavaScript-Sprachfeatures durch jedermann implementierbar und mittels Babel-Plug-ins in Standard-JavaScript-Code transpilierbar sind, der im Browser beziehungsweise Node.js ausgeführt werden kann. Allerdings besitzt Babel dadurch eine komplexe Konfiguration.
Die Dominanz von Googles JavaScript-Engine V8 und der dadurch aufgebaute Konkurrenzdruck gegenüber Mozilla Firefox und Apple Safari führte in den letzten Jahren zu einer beschleunigten Einführung neuer JavaScript-Sprachfeatures. Andere JavaScript-Engine-Hersteller sahen sich dadurch dazu gezwungen, mit neuen Sprachfeatures nachzuziehen. Dadurch geriet die Notwendigkeit des Transpilierens von brandneuen Sprachfeatures gegenüber dem Bundlen – also dem Zusammenführen von JavaScript-Code aus verschiedenen Modulen in einer Datei – in den Hintergrund. Einzig das Transpilieren von JSX-Syntax in JavaScript-Code ist nach wie vor ein wichtiges Feature von Transpilern, da JavaScript-Engines es nicht nativ unterstützen.
Die aktuellen Bundler beschäftigen sich somit hauptsächlich mit dem Bundlen von JavaScript-Code. Andere Dinge wie das Transpilieren von JSX-Syntax werden meist an weitere Tools wie Babel oder Sucrase delegiert und sind überwiegend nicht Bestandteil des eigentlichen Bundlers. Populäre Vertreter dieses Genres sind webpack, Parcel und Rollup.
Die native Unterstützung von ESM (ECMAScript Modules) im Browser, die sich durchgesetzt hat, vereinfacht dieses Konzept. Moderne Browser verstehen das import-Statement und sind dadurch in der Lage, portablen JavaScript-Code in ESM-Form selbstständig nachzuladen und auszuführen.
Moderne Transpilation mit Vite.js und Snowpack
Damit erblickten die aktuellsten Vertreter der Bundler das Licht der Welt: Sie versuchen meist nicht, mit jedem JavaScript- oder Node.js-Feature kompatibel zu sein, sondern schneiden diese alten Zöpfe ab. So kann Vite.js das im Node.js-CJS-Format (CommonJS) distribuierte react-npm-Paket nicht verarbeiten. Stattdessen ist es nötig, eine in ESM transpilierte alternative Variante bereitzustellen. Das alles hat den triftigen Grund, die Turnaround-Zeiten bei der Entwicklung zu minimieren, denn schließlich sind Babel, webpack und Co. mittlerweile recht umfangreich und behäbig geworden.
Vertreter dieser modernsten Generation von JavaScript-Bundlern sind Vite.js und Snowpack. Beiden gemein ist, dass sie im Unterbau komplett auf ECMAScript Modules setzen und im Gegensatz zu webpack, Babel und Co. nur einmal nach ESM transpiliert werden und damit dem Browser direkt verfügbar gemacht werden können. Vite.js stammt von den Machern von Vue.js, lässt sich aber auch für React, Preact und einige weitere Frameworks verwenden. Vor allem das Hot Module Replacement (HMR) – also das Ersetzen von JavaScript-Code zur Laufzeit – hat diese Tools radikal beschleunigt. HMR ist eine ausgezeichnete Sache, die es vereinfacht gesagt erlaubt, eine JavaScript-Quellcodedatei im Editor zu ändern und die Änderung nach dem Speichern ohne Neuladen im Browser unmittelbar sichtbar zu machen.
Sowohl Snowpack als auch Vite.js verwenden unter der Haube zum Transpilieren und zum Bundlen esbuild – sie sind also Wrapper um esbuild. Dadurch laufen sie erheblich schneller als webpack, Rollup oder Parcel.
