Bei der Entwicklung von Web-Frontends gibt es jenseits der reinen Programmierung zahlreiche weitere Aufgaben, die es mehr oder weniger regelmäßig zu erledigen gilt. Dazu zählen beispielsweise das Übersetzen von TypeScript in JavaScript, das Zusammenfügen vieler kleiner Dateien zu wenigen großen Dateien oder das Minifizieren des Quellcodes, der an den Browser ausgeliefert werden soll.
All diesen Aufgaben ist gemein, dass sie – einmal richtig aufgesetzt – nicht sonderlich anspruchsvoll auszuführen sind. Deshalb versuchen EntwicklerInnen, in diesem Bereich einen hohen Grad an Automatisierung zu erreichen.
Die Vorbereitung einer Applikation für das Deployment ist im besten Fall nur ein einziges Kommando. Gleiches gilt für den Entwicklungsbetrieb. Hier kommt es weniger auf die Optimierung des Quellcodes, sondern mehr auf eine bestmögliche Developer Experience an. Die Entwicklungswerkzeuge sollen den Prozess unterstützen und das möglichst aus dem Hintergrund heraus, sodass die EntwicklerInnen sich auf die Umsetzung der Applikation konzentrieren können.
Zu diesem Zweck gibt es eine ganze Klasse von Werkzeugen, die sich zum Ziel gesetzt haben, diese Aufgaben zu erfüllen: die Bundler. Doch was wäre die JavaScript-Welt, wenn es nur ein Werkzeug gäbe, das dieses Problem löst und sich zum weltweiten Standard etabliert hat? Stattdessen ist der Markt der Bundler mehr in Bewegung denn je.
Webpack – der Platzhirsch unter den Bundlern
Lange Zeit gab es den Standard-Bundler für JavaScript: Webpack (siehe unsere Einführung). Dieses mächtige Werkzeug, das selbst in JavaScript implementiert ist, lässt kaum Wünsche offen, wenn es um die Automatisierung des Entwicklungsprozesses geht. Das ist auch der Grund, warum Angular und React mit Create React App auf dieses Werkzeug setzen.
Doch verstecken die Frameworks meist ihre Webpack-Konfiguration vor den EntwicklerInnen. Und das aus gutem Grund: Die Flexibilität und der enorme Funktionsumfang von Webpack haben ihren Preis. Die Konfiguration eines umfangreicheren Web-Frontends kann leicht 1.000 oder mehr Zeilen umfassen. Dabei reicht eine kleine Änderung, und der Buildprozess schlägt fehl oder liefert nicht mehr das gewünschte Ergebnis.
Wenn die Konfiguration so eine große Hürde darstellt, stellt sich die Frage: Wie konnte sich ein so komplexes Werkzeug eine so herausragende Marktstellung erarbeiten? Denn es ist eine Tatsache, dass sich jeder neue Bundler mit dem Standard, den Webpack gesetzt hat, messen muss. Der Hauptgrund liegt in der Architektur von Webpack.
Webpack an sich kann nichts. Was zunächst etwas provokant klingt, ergibt auf den zweiten Blick aber Sinn, denn Webpack verfügt über eine Plugin-Architektur. Das bedeutet, dass das Werkzeug selbst nur einen Rahmen bietet, in den eine große Zahl von Plugins integriert werden kann. Diese liegen in Form von zusätzlichen Paketen vor und werden separat installiert und über die Konfiguration eingebunden. So ist der Kern von Webpack verhältnismäßig klein, und EntwicklerInnen können ihren Buildprozess genau auf ihre Bedürfnisse zuschneiden.
Die Auswahl des richtigen Bundlers
Das wichtigste Kriterium bei der Auswahl eines Bundlers ist, wie gut das Werkzeug die zu erledigende Aufgabe lösen kann. Kann ein Bundler beispielsweise den TypeScript-Code einer Applikation nicht in JavaScript umwandeln, ist das ein Ausschlusskriterium. Für die Auswahl des passenden Bundlers benötigen Sie also eine Liste der Technologien und Features, die das Werkzeug unterstützen muss. Diese können Sie dann mit dem Funktionsumfang der potenziellen Kandidaten vergleichen und auch prüfen, wie gut sich die jeweiligen Plugins konfigurieren lassen.
Eine weitere Metrik, die bei der Auswahl des Werkzeugs von Bedeutung ist, ist, wie sich der Buildprozess konfigurieren lässt. Je einfacher die einzelnen Schritte gesteuert werden können, desto besser. Die Spanne reicht hier von Werkzeugen, die mit Zero-Configuration werben, bis hin zur Komplexität von Webpack.
Auch die Geschwindigkeit eines Bundlers ist relevant bei der Entscheidung für oder gegen ein solches Werkzeug. Die Performance spielt zwar für das Deployment einer Applikation eine große Rolle, da sie die Geschwindigkeit des gesamten Prozesses beeinflusst. Da dieser Prozess aber meist voll automatisiert abläuft, fallen ein paar Sekunden mehr oder weniger nicht ins Gewicht. Viel wichtiger ist die Geschwindigkeit im Entwicklungsprozess. Hier müssen die Änderungen sofort wirksam werden, und der Browser muss für die Anzeige automatisch aktualisiert werden. Ein bedeutendes Feature in diesem Bereich ist das Hot Module Replacement, bei dem Teile einer Applikation ausgetauscht, hinzugefügt oder entfernt werden, ohne dass die Applikation vollständig neu geladen werden muss.
Die Konkurrenten von Webpack
Webpack hat schon viele Konkurrenten kommen und gehen sehen. Doch mittlerweile hat der Bundler wirklich ernstzunehmende Konkurrenz erhalten. EntwicklerInnen können nun Werkzeuge wie Rollup, Parcel, esbuild und seit neuestem Turbopack in Erwägung ziehen.
Rollup
Rollup ist ein moderner Bundler, der viel aus den Fehlern früherer Webpack-Versionen gelernt hat. Rollup selbst ist nicht in JavaScript, sondern in TypeScript implementiert. Rollup setzt bei seiner Architektur auf das bewährte Plugin-Konzept. Zahlreiche Plugins erweitern den Funktionsumfang des Bundlers und stellen so eine hohe Flexibilität sicher. In Sachen Konfiguration ist Rollup deutlich einfacher. Neben Web-Applikationen setzen EntwicklerInnen Rollup auch häufig im Buildprozess von Bibliotheken ein.
Parcel
Der Ansatz von Parcel ist vielversprechend, da es die Einstiegshürde so gering wie möglich hält und zum Einstieg mit Zero-Configuration wirbt. EntwicklerInnen können also ohne die zeitraubende Konfiguration direkt loslegen. Im Vergleich zu Webpack oder Rollup ist Parcel jedoch, was die Verbreitung angeht, weit abgeschlagen. Zwar steigt die Anzahl der Downloads kontinuierlich an, jedoch nicht in dem Maß, wie es bei der Konkurrenz der Fall ist.
esbuild
esbuild steht für extreme Performance. Im Benchmark eines Bundles mit three.js braucht Webpack 39 Sekunden, Rollup 32 Sekunden und Parcel 30 Sekunden. esbuild erledigt diese Aufgabe in 0,37 Sekunden. Im Gegensatz zu Webpack und Rollup ist esbuild nicht in JavaScript oder TypeScript, sondern in Go geschrieben, was mitunter den Geschwindigkeitsunterschied erklärt. esbuild ist allerdings ein noch relativ junger Bundler, was allein schon die 0 als Major-Version verdeutlicht. Ein Produktiveinsatz ist zwar theoretisch möglich, aber zum aktuellen Zeitpunkt noch sehr mit Vorsicht zu genießen.
SWC
SWC ist neben esbuild ein weiteres Beispiel dafür, dass Werkzeuge für die Web-Entwicklung nicht zwingend in JavaScript implementiert werden müssen, denn SWC setzt auf Rust als Programmiersprache. Der Fokus von SWC liegt ebenfalls auf Performance. Deshalb ist auch der Funktionsumfang noch überschaubar. Wie es hier weitergehen wird, wird die Zukunft zeigen.
Turbopack
Ein weiterer vielversprechender Anwärter um die Krone der Bundler ist Turbopack, der mutig von sich behauptet, der Nachfolger von Webpack zu sein. Ganz von der Hand zu weisen ist die Aussage nicht, denn der Hauptentwickler von Turbopack ist gleichzeitig der Erfinder von Webpack. Wie SWC ist auch Turbopack in Rust umgesetzt und erreicht beeindruckende Benchmark-Ergebnisse.
Wie esbuild befindet sich Turbopack noch in einer frühen Entwicklungsstufe, weshalb es noch keine so umfangreiche Community wie bei Rollup oder Webpack gibt. Was Turbopack zu einem ernstzunehmenden Player auf dem Markt der Bundler macht, ist die Tatsache, dass das Unternehmen Vercel hinter der Entwicklung des Werkzeugs steht und somit auch genügend Schwung in der Anfangsphase gegeben sein sollte, um schnell die notwendige Stabilität und Verbreitung zu erreichen.
Die bunte Welt der Modul-Packer – Gibt es den einen richtigen Bundler?
Nein! Es gibt nur passende und weniger passende Werkzeuge. Für uns EntwicklerInnen bietet die aktuelle Entwicklung große Vorteile, da wir eine große Auswahl haben und die verfügbaren Werkzeuge sich gegenseitig zu übertrumpfen versuchen, was in einem größeren Funktionsumfang, besserer Performance und einer guten Developer Experience mündet.
Ungünstig ist nur, dass sich der Markt schnell entwickelt und ein Werkzeug, das heute eine gewisse Stellung auf dem Markt hat, morgen schon wieder in der Versenkung verschwunden sein kann. Deshalb ist die sichere Wette momentan immer noch, auf etablierte Werkzeuge wie Webpack oder Rollup zu setzen.
Titelmotiv: Bild von Alltechbuzz_net auf Pixabay