• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung/Architektur
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Dr. Lars Hupel 16. November 2021

Was macht eigentlich ein Bundler?

Die Kombination

Was kann man sich nun unter "Bundling" vorstellen? Bestimmte Ressourcen, die in mehreren Einzeldateien vorliegen, können problemlos kombiniert werden. Als Beispiel: Mehrere CSS-Dateien, die per <link> im HTML-Code eingebunden werden, können zu einer einzigen Datei zusammengefasst werden, in dem sie einfach konkateniert werden. Aus mehreren nötigen GET-Anfragen an den Server wird dadurch nur noch eine.

Auch bei JavaScript ist das möglich, ja, sogar geboten. Denn Bibliotheken wie React bestehen intern aus zahlreichen Einzeldateien; genau wie man es beispielsweise bei den typischen Backend-Programmiersprachen wie Java gewohnt ist. Zwar können moderne Browser dank dem JavaScript-Modul-Standard (dazu später mehr) auch importierte Referenzen auflösen, doch dies führt zum Problem der "kaskadierenden Requests":

1. Datei frontend.js wird per <script> eingebunden.
2. frontend.js importiert lib.js.
3. lib.js importiert lib/dom.js.
4. lib/dom.js importiert lib/util.js.

... und so weiter. Jede Zeile erzeugt dabei einen eigenen HTTP-Request. Der Browser kann erst anfangen, den JavaScript-Code auszuführen, wenn sämtliche (transitiven) Abhängigkeiten geladen werden.

Die Trennung

Das Gegenmittel dazu lautet "Code Splitting". Statt stumpf alle beteiligten Source-Dateien inklusive Bibliotheken in einer einzigen Datei zu verheiraten, geht man intelligenter vor: Üblicherweise landen externe Abhängigkeiten in einer Datei und anwendungsspezifischer Code in einer anderen Datei. Ein Bundler kümmert sich darum, dass die Import-Pfade korrekt umgesetzt werden, sodass man den Entwicklungsworkflow nicht ändern braucht. Lediglich Konfigurationsdateien müssen angepasst werden.

Code Splitting kann zu gewissem Grad auch manuell durchgeführt werden, da die Konfiguration stellenweise kompliziert ist. Dazu stellen viele Bibliotheken bereits "vorgebundelte" und komprimierte Dateien zum Download zur Verfügung, bei React beispielsweise react.production.min.js. Statt nun im eigenen Code import React from "react" zu schreiben, genügt es, auf die globale Variable React zuzugreifen. Denn das bereitgestellte Bundle exportiert sämtliche Funktionalität in dieser globalen Variable.

In der Praxis könnte der Header eine HTML-Datei dann wie folgt aussehen:

<script src="react.production.min.js"></script>
<script src="react-dom.production.min.js"></script>
<script src="app.js"></script>

Ich rate jedoch von diesem Ansatz ab, wenn man noch weitere Bibliotheken einbindet, weil es dann leicht unübersichtlich wird.

Manche Frontend-Frameworks, so auch React, erlauben zusätzlich, den Anwendungscode weiter zu unterteilen. Dazu kennen neuere JavaScript-Versionen sogenannte "dynamische Imports". Mittels dieser Technik, die in React-Komponenten integrierbar ist, kann ein allgemeines Gerüst von mehreren Webseiten gemeinsam benutzt werden, wobei einzelne Seiten dann ihren spezifischen Code nachladen können. Das passiert automatisch im Hintergrund: Der Browser beginnt bereits damit, das Gerüst zu rendern, bevor die "Innereien" zur Verfügung stehen kann. Ein Beispiel hierfür ist in der React-Dokumentation zu finden:

import React, { Suspense } from 'react';

const InnerComponent =
  React.lazy(() => import('./OtherComponent'));

const MyComponent = () => (
  <div>
    <Suspense fallback={<div>Loading...</div>}>
      <OtherComponent />
    </Suspense>
  </div>
);

Die Referenzen

Unglücklicherweise hat Fingerprinting auch Einfluss auf den eigentlichen Inhalt der Ressourcen. Im vorherigen Abschnitt kann man erkennen, dass zumindest die <script>-Tags angepasst werden müssen. Doch auch andere Assets sind betroffen. Nutzt man etwa SVG-Dateien für Icons, sind deren Pfade in CSS referenziert:

.icon {
  background-image: url("/cool-icon.svg");
}

Aber dank Fingerprinting lautet die URL nun plötzlich anders. Die CSS-Deklaration muss also vom Bundler entsprechend angepasst werden:

.icon {
  background-image: url("/cool-icon.2008714.svg");
}

Es ist daher wichtig, dass der Bundler so konfiguriert ist, dass alle Klassen von Assets durch diesen verarbeitet werden. Intern nutzen sie einen Abhängigkeitsbaum, der nicht nur JavaScript-Dateien, sondern auch Styles usw. umfasst. Bei React-Anwendungen geht man sogar oft noch einen Schritt weiter und "importiert" Styles direkt im JavaScript-Code:

import styles from "./styles.css";

Dabei handelt es sich aber um ein Feature, welches in JavaScript eigentlich nicht existiert. Gewissermaßen erweitert der Bundler damit den Sprachumfang, was zwar einerseits praktisch, andererseits aber nicht portabel ist. Da sich die verschiedenen Bundler teilweise erheblich darin unterscheiden, wie ein solcher Import zu handhaben ist, gehen wir hier nicht weiter darauf ein.

Die Übersetzung

Ganz ohne Spracherweiterungen kommt man aber – zumindest bei React – nicht aus. Denn React nutzt den JavaScript-Dialekt "JSX", der es erlaubt, HTML-Tags in JavaScript zu verwenden.
Beispiel:

const tree = (
  <ul>
    { items.map(item => <li>{item}</li>) }
  </ul>
)

Dieser Code erzeugt zur Laufzeit eine HTML-Liste (<ul>) mit mehreren Einträgen (<li>), die sich aus dem Array items ergeben. Browser verstehen diese Syntax jedoch nicht. Über Sinn und Unsinn von JSX möchte ich hier nicht philosophieren, sondern erklären, wie daraus tatsächlicher JavaScript-Code entsteht. Auftritt der "Transpiler"...

Ein Transpiler, oder auch "Trans-Compiler", ist ein Werkzeug, mit dem ein JavaScript-Dialekt in einen anderen übersetzt wird. Der populärste dieser Art ist "Babel", dessen Name bereits mit einem Augenzwinkern auf die biblische Sprachverwirrung hindeutet. Babel kann nun den obigen JSX-Code zerkauen und folgenden JS-Code ausspucken:

const tree = React.createElement(
  "ul",
  null,
  {
    children: items.map(item =>
      React.createElement("li", null, item)
    )
  }
)

Nun ist der Code von idiosynkratischen Features befreit und alle Browser können – vorausgesetzt, React ist als Abhängigkeit geladen – damit umgehen. Oder?

Leider muss Babel oft noch mehr tun, denn moderner JavaScript-Code nutzt oft weitere Features, die zwar standardisiert, aber noch längst nicht in allen Browsern verfügbar sind. Oft steht hier Internet Explorer 11 auf der Bremse, von dem manche Anwendungen (und Anwender:innen) noch abhängig sind. Dieser hängt ungefähr ein Jahrzehnt zurück, unterstützt also nicht einmal das class-Schlüsselwort. Babel kann solche Features ebenfalls entfernen und erzeugt auf Wunsch auch solcherlei prähistorischen JS-Code.

Die technologie-agnostische Datenbank "Browserslist" führt Buch über Browser-Versionen und deren Unterstützung von Sprach-Versionen. Möchte man derart transpilieren, legt man eine Konfigurationsdatei an, die z. B. so aussieht:

Last 2 versions
IE 11
> 5% in DE

Babel wertet diese Datei automatisch aus und konfiguriert sich selbst so, dass von jedem Browser die zwei jüngsten Versionen unterstützt werden, sowie zusätzlich IE 11 und die mit mehr als 5 Prozent deutschlandweitem Marktanteil. Alle Features, die nicht von den angegebenen Browsern unterstützt werden, werden von Babel transpiliert. Obacht: Nicht immer ähnelt das Kompilat dem Original; stellenweise muss Babel allerlei Helferlein injizieren, um neue Features zu emulieren.

Der Kitt

Wer denkt, dass damit die Unterstützung von alten Browsern abgedeckt ist, hat leider die Rechnung ohne die Web-APIs gemacht. Denn nicht nur entwickelt sich JavaScript als Sprache weiter, sondern auch die Browser stellen mit atemberaubender Geschwindigkeit neue APIs bereit. Beispielsweise kann man mit den "Custom Elements" – wie der Name schon sagt – eigene HTML-Tags definieren, die ihre Inhalte mit weiteren Funktionen anreichern können.

Für die armen 5 Prozent der User, deren Browser damit nichts anfangen kann (danke, IE!), kann Babel auch nichts tun, denn als reiner Transpiler weiß er nichts von Programmierschnittstellen. Ähnlich verhält es sich z. B. mit fetch, dem wesentlich einfacher zu bedienenden Nachfolger von XMLHttpRequest. Was also tun?

Die Lösung lautet "Polyfills", ein Bündel an sehr verschiedenen Technologien, die nach einer Spachtelmasse-Marke benannt sind. Für viele moderne APIs gibt es ein Polyfill, welches normalerweise ein Schnipsel JavaScript-Code ist, der so weit wie möglich die API mit Basismitteln des Browsers nachbildet. Das funktioniert nicht immer vollständig, insbesondere wenn das neue Feature tief im Browser verankert ist. Im Falle von fetch implementiert der passende Polyfill die Funktionalität eben auf Basis von XMLHttpRequest und verpasst diesem damit einen neuen Anstrich.

Zu beachten ist jedoch, dass jeder Polyfill die Größe der Webseite aufbläht. Bei der Architektur muss man also entscheiden, ob nicht doch lieber den "Progressive Enhancement"-Ansatz fährt: Man gestaltet die Webseite so, dass sie auch ganz ohne JavaScript auskommt. Moderne Browser bekommen dann noch weitere Annehmlichkeiten als Dreingabe. Custom Elements eignen sich dafür ganz vorzüglich. Ganz im Vorbeigehen baut man auch gleich noch Barrieren ab, sodass die Webanwendung für eingeschränkte User (z. B. alte Smartphones oder Nutzer:innen mit Screenreader) bedienbar bleibt.

Allerdings verträgt sich Progressive Enhancement nur bedingt mit Single Page Applications. Bei diesen ist man oftmals gezwungen, großflächig Spachtelmasse auszubringen.

Beiden Ansätzen ist aber gemeinsam, dass sie – um sie korrekt anwenden zu können – einiges an Vorab-Arbeit erfordern, um die konkreten Anforderungen im Projekt auszuloten und die Weichen für die Entwicklung entsprechend zu stellen. Entscheidet man sich für Polyfills, können Bundler diese automatisch in die erzeugten Bundles injizieren. Stellenweise können sie sogar die benötigten Polyfills anhand der Quelltexte und der Browserslist-Konfigurationen inferieren.

Zusätzlich sollte man beachten, dass das Transpilieren von Sprachfeatures, wie es Babel praktiziert, üblicherweise die Semantik erhält, aber Polyfills ihrer Natur nach Kompromisse eingehen müssen. Sorgfältiges Lesen der Dokumentation ist also Pflicht.

Die Bilder

Während Babel vortrefflich mit JavaScript umgehen kann, betrifft kränkelnder Browser-Support oder Preprocessing auch noch andere Arten von Assets. Beispielsweise können moderne Browser mit den Bildformaten WEBP und AVIF umgehen, die deutlich kleinere Dateien als JPG erzeugen. HTML 5 bietet die Möglichkeit an, mehrere verschiedene Bildformate zu deklarieren und die Wahl dem Browser zu überlassen:

<picture>
  <source type="image/avif" srcset="pic.avif">
  <source type="image/webp" srcset="pic.webp">
  <img alt="A dog with a hat" src="pic.jpg">
</picture>

Ein Browser, der damit nichts anfangen kann, lädt wie gehabt das JPG-Format. Kann er allerdings AVIF rendern, so lädt er kurzerhand diese Version. Stand Oktober 2021 können weltweit nur ca. zwei Drittel der Web-User AVIF-Dateien anzeigen. Diese profitieren dann aber von deutlich schnellen Ladezeiten.

Dieses Problem lässt sich noch beliebig verkomplizieren, denn um der Webseite auf Touren zu bringen, kann man auch für verschiedene Displaygrößen verschieden große Bilder ausliefern. Da spätestens hier viele Bundler aussteigen, gibt es einige spezialisierte Drittanbieter, die je nach Request Bilder "on the fly" skalieren, konvertieren und optimieren können – selbstredend mit Caching-Support. Die eingesetzte Technologie wird als "Content Negotiation" bezeichnet, wobei der Anbieter die Request-Header des Browsers auswertet, um festzustellen, womit dieser umgehen kann.

Technisch gesehen hat das Transcoding und Skalieren von Bildern so gar nichts mit der Verarbeitung von JavaScript zu tun, gehört also eigentlich nicht zu der Kernaufgabe von Bundlern. Dennoch können viele Asset-Pipelines auch hiermit umgehen, denn sie unterstützen es beispielsweise, besonders kleine Ressourcen zu inlinen. So kann z. B. ein Bild wie folgt optimiert werden: aus

<img alt="Loading" src="spinner.gif">

mach

<img alt="Loading" src="data:image/gif;base64,
iVBORw0KGgoAAAANSUhEUgAAA...">

Diese Ersetzung kann sowohl in HTML, CSS als auch  JavaScript-Ressourcen stattfinden. Ähnliche Überlegungen zur Abwägung zwischen Cachebarkeit und kaskadierenden Requests wie beim Code Splitting sind auch dafür anzustellen.

Das Komprimieren

Bleibt noch eine letzte wichtige Aufgabe von Bundlern: Das sogenannte "Tree Shaking"; anderswo auch bekannt als "Dead Code Elimination".

Auf Server-Seite ist es meist egal, wie groß das lauffähige Artefakt ist. Sämtliche transitiven Abhängigkeiten – auch wenn sie am Ende gar nicht gebraucht werden – sind im Image inkludiert. Wie hier bereits lang und breit erläutert, ist clientseitig die Bandbreite kostbar.

Tree Shaking beschreibt den Prozess, mit dem Bundler ungenutzte Source-Dateien aus dem erzeugten Bundle "herausschütteln". Dazu müssen sie sich eigentlich nicht besonders anstrengen, denn einen Abhängigkeitsbaum benötigen sie zum Fingerprinting ohnehin. Eigentlich....

Denn viele Bundler unterstützen das Tree Shaking unterhalb der Dateiebene, namentlich auf Ebene individueller Definitionen. Dazu müssen sie z. B. bei Konstanten eruieren, ob diese "rein" sind. Beispielsweise darf folgende Definition nicht gelöscht werden, selbst wenn nicht auf x zugegriffen wird:

function f() {
  console.log("hello world!");
  return 3;
}

const x = f();

Eine Definition const x = 3 hat hingegen eine weiße Weste und darf nach Belieben entsorgt werden.

Zur Kompression gibt es noch weitere Techniken, z. B. das Umbenennen von langen Klassen-, Funktions- und Variablennamen. Natürlich bekommt man damit in einer derart dynamischen Sprache wie JavaScript, wo Feldzugriffe auch per String möglich sind, noch einmal eine Extraportion Fallstricke. Entsprechend sollten Tests auch, wenn möglich, die fertig verarbeiteten Artefakte prüfen.

Die Entwicklung

Hat man die Webanwendung mithilfe eines Bundlers gründlich performancemäßig tiefergelegt, hat das Resultat, welches vom Browser ausgeführt und angezeigt wird, oftmals nur noch eine begrenzte Ähnlichkeit mit dem Original. Insbesondere der oben beschriebene letzte Schritt macht der Lesbarkeit den Garaus.

Doch auch dagegen gibt es ein Rezept. Im Debug-Modus kann man Bundler derart konfigurieren, dass sie eine "Sourcemap" ausgeben. Dabei wird der – mehr oder weniger unveränderte – Quelltext als Kommentar im Header des Kompilats abgelegt. Natürlich führt das sämtliche Größenersparnisse ad absurdum, deswegen sollte man dies nicht in Produktion anschalten. Aber während der Entwicklungsphase können Browser anhand der Sourcemap z. B. akkurate Stacktraces rekonstruieren, was die Fehlersuche deutlich vereinfacht.

Um konkrete Benchmarks kommt man aber nicht umhin. Zum einen kann man dafür den bei allen modernen Browsern mitgelieferten Web Inspector benutzen, der die Netzwerkrequests mit und ohne Cache anzeigen kann. Damit lassen sich schnell Flaschenhälse identifizieren. Ein weiterer Baustein sind automatische Tools, die auch noch andere Probleme – wie beispielsweise fehlerhafte Darstellung in mobilen Endgeräten – aufdecken können.

Autor