Ich habe ESLint + Prettier 2026 durch Biome ersetzt — hier ist der Benchmark

Über ein Jahrzehnt lang war die Antwort auf “wie halte ich mein JavaScript sauber?” derselbe zweiköpfige Reflex: eslint installieren, prettier installieren und dann einen Nachmittag damit verbringen, beide so zu verdrahten, dass sie aufhören, sich zu streiten. Dazu der TypeScript-Parser, ein Import-Plugin, ein React-Plugin, ein Barrierefreiheits-Plugin, eine Konfiguration, um die Regeln abzuschalten, die Prettier ohnehin erledigt — und du endest bei einem Dutzend Abhängigkeiten und vier Konfigurationsdateien, nur um Code zu formatieren und zu linten, den du noch gar nicht geschrieben hast.

Biome faltet diesen ganzen Stapel in ein einziges Binary. Es ist ein Formatter, ein Linter und ein Import-Sortierer, geschrieben in Rust, konfiguriert über eine einzige biome.json, schnell genug, dass du aufhörst, “Linten” als Schritt zu begreifen, auf den du wartest. Dieser Artikel ist ein praxisnaher Blick darauf, was es tatsächlich ersetzt, wie die Migration wirklich läuft, wie die Benchmark-Zahlen aussehen und — genauso wichtig — was du beim Wechsel aufgibst.

Das ist die Tooling-Hälfte eines größeren 2026-Themas — die schweren Defaults löschen, die du aus Reflex installiert hast. Wenn du auch lodash mitschleppst, gilt dieselbe Logik für deine Utilities: siehe lodash löschen: es-toolkit ist 2x schneller und 97% kleiner.

Was Biome eigentlich ist

Biome ist der Nachfahre des Rome-Projekts: eine Toolchain für Web-Sprachen, gebaut in Rust statt in JavaScript. Statt eines Formatters hier und eines Linters dort, jeder mit eigenem Parser und eigenem Konfigurationsdialekt, parst Biome deinen Code einmal und führt alles gegen diesen einen Baum aus:

• Formatter — ein opinionierter Formatter in der Prettier-Tradition, mit kompatiblem Stil für JavaScript, TypeScript, JSX, JSON und CSS.
• Linter — Hunderte Regeln für Correctness, verdächtigen Code, Stil und TypeScript, plus Framework-Regeln für React und Barrierefreiheit.
• Import-Sortierung — deterministische Import-Organisation, ohne separates Plugin.

Das alles kommt als eine Abhängigkeit, @biomejs/biome, und liest eine Konfigurationsdatei. Das ist der ganze Pitch: weniger bewegliche Teile, eine Quelle der Wahrheit.

npm install --save-dev --save-exact @biomejs/biome
npx biome init

biome init legt eine biome.json mit sinnvollen Defaults an. Von da an sind Formatieren und Linten je ein einziger Befehl:

npx biome format --write .
npx biome lint .
# oder beides plus Import-Sortierung in einem Durchlauf:
npx biome check --write .

Der Schmerz, den es beseitigt: der Plugin-Sumpf

Biome trifft einen Nerv nicht wegen Neuheit, sondern wegen Ermüdung. Ein ausgereiftes ESLint-+-Prettier-Setup sieht typischerweise so aus, bevor du eine einzige eigene Regel konfiguriert hast:

Jedes dieser Pakete hat seinen eigenen Release-Takt, seine eigenen Peer-Dependency-Anforderungen und seine eigene Art, bei einem Major-Update zu brechen. Die eslint-config- und eslint-plugin-Matrix ist eine echte Wartungssteuer: jemand im Team hält sie konsistent, und jedes Upgrade ist eine kleine Verhandlung. Die Aufteilung .eslintrc / .prettierrc bedeutet zwei Konfigurationsdialekte — und den Klassiker, dass Prettier und ESLint über dieselbe Zeile uneins sind, bis du eslint-config-prettier hinzufügst, damit sie aufhören.

Biome ersetzt das ganze Diagramm durch zwei Dinge: das @biomejs/biome-Binary und eine biome.json. Es gibt keinen Plugin-Auflösungsschritt, keinen Peer-Dependency-Graphen und keinen Revierkampf zwischen Formatter und Linter, weil Formatter und Linter dasselbe Programm sind.

Die Migration: ein Kommando, kein Rewrite

Die Angst bei jedem “ersetze dein Tooling”-Pitch sind die Migrationskosten. Biome beantwortet sie direkt mit eingebauten Migrationsbefehlen, die deine bestehende Konfiguration lesen und übersetzen:

# ESLint-Regeln in biome.json übersetzen
npx biome migrate eslint --write

# Prettier-Optionen in biome.json übersetzen
npx biome migrate prettier --write

Diese Befehle parsen deine .eslintrc und .prettierrc (inklusive extends-Ketten und Overrides) und bilden sie auf Biomes Pendants ab, sodass deine Zeilenbreite, dein Quote-Stil, deine Semikolon-Präferenz und die von Biome unterstützten Regeln übernommen werden. Du prüfst die entstandene biome.json, löschst die alten Konfigurationsdateien und ihre Abhängigkeiten und verdrahtest Biome in deine Skripte:

{
  "scripts": {
    "format": "biome format --write .",
    "lint": "biome lint .",
    "check": "biome check --write ."
  }
}

Installiere die offizielle VS-Code-Erweiterung und setze Biome als Standard-Formatter, und das Editor-Erlebnis ist dasselbe “Format on Save”, das du schon hattest — nur schneller und aus einem Tool.

Der Benchmark

Das ist der Teil, den alle wirklich sehen wollen, also lass uns genau sein, was die Zahlen bedeuten. Biome ist schnell, weil es natives Rust ist, jede Datei einmal parst und über alle Kerne läuft. ESLint und Prettier zahlen obendrauf Node.js-Start, Plugin-Auflösung pro Datei und Single-Thread-Parsing.

Das Diagramm unten ist auf die Verhältnisse der offiziellen Biome-Benchmarks skaliert — es zeigt die Form des Unterschieds auf einer großen Codebasis, kein Versprechen für dein exaktes Repo:

Die Kernaussage aus Biomes eigenen veröffentlichten Benchmarks ist, dass der Formatter in der Größenordnung von 25x schneller als Prettier läuft und das Linten rund 20x schneller als ESLint. In der Praxis zeigt sich der Gewinn an zwei Stellen:

• CI — ein Lint-und-Format-Check, der früher mehrere Sekunden dauerte, fällt auf einen Bruchteil einer Sekunde, und das zählt, wenn er bei jedem Push über jeden PR läuft.
• Der Editor — Format on Save und Lint on Type fühlen sich selbst bei großen Dateien sofort an, weil keine Plugin-Pipeline hochgefahren werden muss.

Der ehrliche Vorbehalt: die absoluten Zeiten hängen vollständig von deiner Codebasis, deiner Maschine und deinem Regelset ab. Liefere nicht die Zahl eines anderen als deine eigene aus. Miss es selbst — es dauert zwei Minuten:

# hyperfine installieren (brew install hyperfine) und Wall-Clock-Zeit vergleichen
hyperfine --warmup 3 \
  'npx prettier --write "src/**/*.{ts,tsx}"' \
  'npx biome format --write src'

hyperfine --warmup 3 \
  'npx eslint "src/**/*.{ts,tsx}"' \
  'npx biome lint src'

Das Verhältnis in deinem Terminal ist die Zahl, die in die Entscheidung deines Teams gehört — und in meiner Erfahrung landet es in derselben Größenordnung, die die offiziellen Benchmarks berichten.

Was du tatsächlich verlierst

Ehrlichkeit zählt mehr als Hype, also hier der Gegenfall — die Dinge, die du abwägen solltest, bevor du .eslintrc löschst:

• Das Plugin-Ökosystem. Das ist der große Punkt. ESLint hat Tausende Community-Regeln und Framework-spezifische Plugins. Biome deckt die verbreiteten ab und ergänzt mit jedem Release mehr, aber wenn du von einem Nischen-Plugin oder einer maßgeschneiderten internen Regel abhängst, gibt es vielleicht noch kein Biome-Pendant.
• Eigene Regeln. Wenn dein Team eigene ESLint-Regeln geschrieben hat, um interne Konventionen zu erzwingen, portieren die nicht. Biomes Plugin-Story wächst, aber es ist nicht dasselbe offene eslint-plugin-Modell.
• Long-Tail-Sprach- und Format-Support. Biomes Sprachabdeckung (JS/TS/JSX/JSON/CSS und wachsend) ist stark, aber nicht universell; ein Prettier-Plugin für einen exotischen Dateityp hat vielleicht kein Pendant.

Das pragmatische Muster, bei dem die meisten Teams landen, ist nicht “ESLint für immer löschen”. Es ist: Biome für die Formatierung und für jede Lint-Regel nutzen, die es abdeckt — was die überwältigende Mehrheit dessen ist, was ein normales Projekt verwendet — und eine schlanke ESLint-Konfiguration nur für die spezifischen Plugin-Regeln behalten, die Biome noch nicht erreicht hat. Du löschst trotzdem den Großteil des Stapels; du behältst nur das eine Plugin, auf das du wirklich nicht verzichten kannst.

Fazit: wann wechseln, wann nicht

Wechsle zu Biome, wenn du willst, dass Formatter und Linter ein schnelles Tool ohne Konfigurations-Drama sind, wenn dein Regelbedarf durch das eingebaute Set abgedeckt ist und wenn du es leid bist, die ESLint-+-Prettier-Plugin-Matrix zu pflegen. Für ein neues Projekt 2026 ist Biome zuerst zu greifen der sinnvolle Standard — du bekommst Formatierung, Linting und Import-Sortierung in einem install, und eine CI, die fertig ist, bevor du den Tab gewechselt hast.

Bleib bei ESLint — oder betreibe es neben Biome — wenn dein Projekt auf Nischen-Plugins oder eigene Regeln setzt, die Biome noch nicht implementiert hat. Nutze in dem Fall Biome für die Formatierung und die abgedeckten Regeln und behalte eine minimale ESLint-Konfiguration für den Rest. Du wirst trotzdem den Großteil des Gewichts los.

Der Punkt ist nicht, einem neuen Tool um seiner selbst willen hinterherzujagen. Es ist, dass Formatieren und Linten aufgehört haben, ein Ort zu sein, an dem du Nachmittage in Konfiguration und Sekunden in jeden CI-Lauf stecken solltest. Biome macht beides beinahe kostenlos.

npm install --save-dev --save-exact @biomejs/biome
npx biome migrate eslint --write
npx biome migrate prettier --write
npx biome check --write .