Baseline: Das Geheimnis, um deutlich weniger JavaScript auszuliefern

Baseline: Das Geheimnis, um deutlich weniger JavaScript auszuliefern

Weißt du noch, als jQuery alles einfacher gemacht hat? Einfach eine 90-KB-Datei ins Projekt geworfen, und plötzlich fühlte sich `$(document).ready()` an wie Butter. Dann wurden wir schlauer, haben unsere Bundles aufgeteilt und jQuery gegen React, Vue und einen ganzen Schrank voller Mikro-Bibliotheken getauscht.

Und trotzdem erwische ich mich immer wieder dabei: Ich greife zu einer 20-KB-Datumsformatierungs-Bibliothek, obwohl der Browser, den ich als Ziel habe, längst eine API hat, die genau dasselbe kann. Kostenlos. Kein Network-Request. Kein Versions-Bump. Keine zukünftige Wartung.

Genau da kommt **Baseline** ins Spiel.

Falls du es noch nicht kennst: Baseline ist eine W3C-unterstützte Initiative, die uns ein einfaches, universelles Etikett dafür gibt, „ab wann kann ich diese Funktion bedenkenlos nutzen?" Sie beantwortet die nervigste Frage in der Webentwicklung mit einem einzigen Wort: **heute**. Und weil Baseline dir hilft zu erkennen, was die Web-Plattform schon kann, kann es das JavaScript, das du auslieferst, massiv verkleinern. Schauen wir uns an, wie.

Was ist Baseline eigentlich?

Baseline ist ein gemeinsames Verständnis von Browser-Support über alle großen Player hinweg: Chrome, Edge, Firefox, Safari und Opera. Statt einer Matrix mit „funktioniert in 97 % der Browser" sagt Baseline dir, ob ein Feature **available** ist (funktioniert in aktuellen Browsern) oder **newly available** (gerade in den neuesten Versionen gelandet). Die Idee dahinter: keine Rätselraten mehr.

Stell es dir vor wie „caniuse, aber mit einem freundlicheren Urteil.“ Sobald ein Feature Baseline wird, heißt das: Jeder Browser im gemeinsamen Ökosystem unterstützt es. Das ist dein grünes Licht.

Und das Beste: Baseline steckt bereits an Orten, die du wahrscheinlich sowieso benutzt. Schau in die Kompatibilitätstabellen von MDN, such ein Feature, und du siehst direkt daneben ein Baseline-Badge. Oder wirf einen Blick auf [web.dev/baseline](https://web.dev/baseline) für ein Dashboard darüber, was heute bereit ist.

Warum das für deine Bundle-Größe wichtig ist

Der Abstand zwischen „dafür brauchst du eine Bibliothek" und „das kann der Browser schon" wird immer kleiner. Jedes Jahr kommen APIs dazu, für die man früher Polyfills, Helfer-Libraries und Utility-Funktionen brauchte. Wenn du immer noch `moment-timezone` für Zeitzonen-Berechnungen oder `lodash` für `_.debounce()` auslieferst, bezahlst du für etwas, das die Plattform längst mitbringt – sowohl in Bytes als auch in Komplexität.

Ich zeige dir drei praktische Beispiele, bei denen Baseline dir hilft, unnötigen Ballast loszuwerden.

Szenario 1: Datumsformatierung ohne die 50-KB-Abhängigkeit

Ich habe mal an einem Projekt gearbeitet, das `date-fns` importiert hat, nur um ein paar Daten in einem Dashboard zu formatieren. Die ganze Anwendung war ein statisches Dashboard. Wir haben 16 KB lokalisierte Datumsfunktionen ausgeliefert, nur um Strings wie „9. August 2026" zu erzeugen.

Und jetzt ein kleines Experiment: Öffne die Konsole deines Browsers und tipp das ein:

```js
new Intl.DateTimeFormat('de-DE', { dateStyle: 'full' }).format(new Date())
```

Das war's. **Kein Import, kein npm install, kein Version-Pinning.** Das `Intl`-Objekt ist seit Jahren ein Baseline-Feature. Es kann lokalisierte Formatierung, Zeitzonen und sogar date-fns-artige relative Zeitangaben mit `Intl.RelativeTimeFormat`.

Willst du das ganze Bundle loswerden? Dann ersetze deine date-fns-Funktionen durch die nativen Entsprechungen:

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (oder `new Date()`, mit Vorsicht)
- `zonedTimeToUtc` → `Intl` mit der `timeZone`-Option

Ja, es gibt Edge Cases. Aber für 90 % der Projekte reicht die native Intl-API. Und sie ist Baseline available, also läuft sie in jedem modernen Browser.

Szenario 2: Lodash durch das DOM ersetzen

Ich sehe immer noch `lodash.debounce` in Codebasen. Fünf Kilobyte, nur damit eine Funktion kurz wartet, bevor sie läuft. Dabei hat der Browser das schon eingebaut:

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

Oder wenn du wie ich eher faul bist: Ein simples `setTimeout` im Event-Listener reicht in den meisten Fällen. Gleiches gilt für `_.throttle`, `_.clamp`, `_.range` – alles nur ein paar Zeilen Vanilla JavaScript.

Aber es kommt noch besser. `_.forEach`? Das Array-Prototype hat `forEach`, `map`, `filter`, `reduce` – alles Baseline. `_.get` für den sicheren Zugriff auf verschachtelte Properties? Optional Chaining ist seit 2020 ein Baseline-Feature. `_.unique`? Das ist einfach `Set`.

Auch das DOM selbst ist eine Goldgrube: `classList.toggle()` ersetzt `_.toggleClass`, `Element.matches()` ersetzt `_.is()`-Selektoren, und mit dem nativen `IntersectionObserver` kannst du ganze Scroll-Spy-Bibliotheken streichen. Wenn du das nächste Mal eine Abhängigkeit einbauen willst, frag dich: „Ist das nur ein hübscher Wrapper um etwas, das mir `document.querySelectorAll` schon längst gibt?"

Szenario 3: HTTP-Requests ohne axios

Axios ist eine wunderschöne Bibliothek, aber im Jahr 2026 ist die native `fetch`-API Baseline und deckt fast jeden Use Case ab. Streaming? `fetch` kann mit `response.body.getReader()`. Authentifizierung? Du kannst Header, Credentials und Interceptors mit einem kleinen Wrapper setzen. Abbrechen? `AbortController` – auch Baseline.

Für ein kleines Projekt habe ich axios komplett durch einen 20-Zeilen-Helfer ersetzt:

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

Kein npm, kein `node_modules`-Ballast, keine Circular-Dependency-Warnungen. Einfach schnell, nativ und zuverlässig.

So prüfst du deine Dependencies wirklich mit Baseline

Überzeugt? Dann jetzt der praktische Teil. Das kannst du heute Nachmittag durchziehen.

1. Alle Runtime-Dependencies auflisten

Lass `npm ls --production` laufen oder wirf einen Blick in deine `package.json`. Markiere alles, was nicht dein Framework oder eine State-Management-Library ist. Genau diese kleinen Utility-Pakete sind die besten Kandidaten.

2. Jede Dependency mit Baseline abgleichen

Stell bei jeder Bibliothek auf deiner Liste zwei Fragen:

- Welches Problem löst sie?
- Kann ich das mit einer Web-API lösen, die Baseline available ist?

Such die Funktion auf MDN. Wenn du das grüne „Baseline available"-Badge siehst, bist du gut unterwegs. Bei „Newly available" und modernen Browser-Zielen kannst du es trotzdem in Betracht ziehen. Wenn dort „Limited" steht, lass die Bibliothek erstmal drin.

Ein Tipp noch: Öffne die DevTools in Chrome, Safari oder Firefox und teste die API direkt. Wenn sie ohne Flag funktioniert, ist das ein sehr gutes Zeichen.

3. Code nach verdächtigen Mustern durchsuchen

Such nach Mustern wie `import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'` oder `from 'jquery'`. Schau dann, wie oft diese Funktionen wirklich verwendet werden. Manchmal stellst du fest, dass du nur drei Methoden aus einer Bibliothek mit 200 Methoden nutzt. Das ist eine klare Chance.

4. Ersetzen und vergleichen

Migriere immer nur eine Bibliothek auf einmal. Leg einen eigenen Pull Request an, damit du die Änderung der Bundle-Größe messen kannst. Nutz den Size-Report deines Build-Tools oder prüf die Dateigröße in den DevTools. Ich empfehle, vorher und nachher einmal Lighthouse laufen zu lassen. Zu sehen, wie die „JavaScript execution time" fällt, ist ein wunderschönes Gefühl.

Die menschliche Seite von weniger JavaScript

Warum ist uns das wichtig, außer für das wohlige Gefühl, ein kleineres Bundle zu haben? Weil JavaScript die teuerste Ressource ist, die wir an Browser schicken. Jedes Byte muss heruntergeladen, geparst, kompiliert und ausgeführt werden. Jede gesparte API bedeutet: eine schnellere Seitenladung für jemanden mit einem billigen Android-Handy und wackeligem 3G. Nicht alle sitzen mit einem MacBook Pro am Glasfaserkabel.

Weniger JavaScript bedeutet aber auch: weniger kognitive Belastung für dich. Jede Dependency ist eine potenzielle Sicherheitslücke, ein möglicher Migrationsalbtraum und eine Quelle für seltsame Bugs, wenn der Maintainer irgendwann aufhört. Native APIs werden von den Browserherstellern gepflegt – das heißt, sie werden jahrelang aktualisiert, dokumentiert und unterstützt.

Und da ist noch ein tieferer Nutzen: Du fängst an, die Web-Plattform selbst zu verstehen. Wenn du `Intl`, `URL`, `Promise`, `Map`, Optional Chaining und `fetch` direkt benutzt, wirst du ein besserer Webentwickler. Du bist nicht nur Konsument von Abstraktionen, sondern jemand, der die Maserung des Holzes kennt, mit dem er arbeitet.

Gibt es Einschränkungen? Ja. Also benimm dich nicht.

Baseline ist kein Zauberstab. Einige fortgeschrittene APIs sind noch zu neu, um überall Baseline available zu sein. Die Popover API oder die View Transitions API zum Beispiel sind „newly available", aber noch nicht in allen Browsern angekommen. Wenn du eine öffentliche Website für ein breites Publikum baust, warte lieber oder biete einen Graceful Fallback an.

Außerdem heißt eine Bibliothek streichen nicht automatisch, dass du weniger Code schreibst. Manchmal musst du ein bisschen mehr Vanilla JavaScript schreiben, um dasselbe Verhalten zu erreichen. Aber hey: Ein paar Zeilen eigener Code sind wartbarer als eine monolithische Utility-Bibliothek, die du nicht komplett verstehst.

Und zum Schluss: Werde kein „Native-API-Fanatiker." Wenn eine Bibliothek deine Produktivität komplett verändert und dein Leben leichter macht, dann nutze sie. Bei Baseline geht es nicht darum, dich zu beschämen, weil du tolle Bibliotheken verwendest. Es geht um informierte Abwägungen. Aber bitte liefer nicht `safe-password-generator` aus, wenn `crypto.getRandomValues()` schon seit 2015 Baseline ist.

Bonus: So bleibst du bei Baseline auf dem Laufenden

Die Web-Plattform entwickelt sich schnell. Um mitzubekommen, was gerade Baseline available wird, mache ich zwei Dinge:

1. Ich schaue ungefähr einmal im Monat auf das **Web Platform Features**-Dashboard unter [web.dev/baseline](https://web.dev/baseline).
2. Ich lese den **MDN Baseline News**-Bereich, der jeden Monat neu verfügbare Features auflistet.

Du kannst auch das GitHub-Repo der WebDX Community Group unter [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline) verfolgen. Da passiert die Magie.

FAQ: Häufige Fragen

Was bedeutet „Baseline available" genau?

Ein Feature wird in den aktuellen und letzten Versionen aller großen Browser unterstützt – Chrome, Edge, Firefox, Safari und Opera. Du kannst es ohne Polyfill oder Fallback für diese Browser nutzen.

Ist Baseline dasselbe wie caniuse.com?

Nein, aber verwandt. Caniuse liefert detaillierte Kompatibilitätstabellen, auch für ältere Versionen. Baseline destilliert diese Daten in ein einfaches „fertig oder nicht fertig"-Etikett. Und es ist kontextsensitiv – nur weil etwas in Chrome 120 funktioniert, heißt das nicht, dass es in Safari 12 funktioniert.

Was ist, wenn ich noch einen älteren Browser wie den IE11 unterstützen muss?

Der IE11 ist tot, und schon vorher war er eine Ausnahme. Baseline schließt Legacy-Browser wie den IE11 explizit aus. Wenn du solche uralten Umgebungen unterstützen musst, musst du dir die einzelnen Kompatibilitätstabellen ansehen und eventuell Polyfills für die APIs einbauen, die du verwendest. Aber im Jahr 2026 darf man fragen, warum du den IE11 immer noch unterstützt – deine Nutzer entscheiden sich für alte Technik, und du zahlst den Preis.

Wie überzeuge ich mein Team, Baseline zu nutzen?

Zeig ihnen die Zahlen. Nimm eine Dependency, schätz die Bundle-Größe und die Wartungskosten, und zeig dann in einem schnellen Prototyp den nativen Ersatz. Ich habe das mit `lodash` in einem früheren Job gemacht, und als mein Lead den Diff sah – eine 5-KB-Utility, ersetzt durch zwei Zeilen Vanilla JavaScript – war er überzeugt. Und schick ihnen diesen Post. 😉

Fazit

Baseline ist nicht nur ein weiteres Kompatibilitäts-Tool – es ist ein Mindset-Wechsel. Statt zu fragen „Welche Bibliothek brauche ich dafür?", fragst du dich: „Was kann der Browser schon für mich tun?" Sobald du diesen Wechsel machst, schmilzt der JavaScript-Ballast dahin.

Deine Nutzer bekommen eine schnellere Website. Dein zukünftiges Ich bekommt eine sauberere Codebase. Und das Web wird ein kleines bisschen leichter für alle.

Und jetzt: Öffne deine DevTools, schau dir das Bundle deines Projekts an und überleg, was du wegwerfen kannst. Dein Browser wartet wahrscheinlich schon mit der Antwort.