Suggest an editImprove this articleRefine the answer for “Why is Biome faster than its alternatives?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Biome** is faster than its alternatives primarily because it is written in **Rust**, uses a single high-performance parser, and performs one centralized AST traversal instead of the several separate passes that ESLint and Prettier require. **Key point:** 2 tools → 1 engine → 1 pass → faster.Shown above the full answer for quick recall.Answer (EN)Image## Why is Biome faster? ### **1. Biome is written in Rust** The main reason is Rust. - Rust compiles to native machine code - There is no garbage collector - High optimization of computations - Excellent multithreading support Compared to JavaScript (in which ESLint and Prettier are written), Rust works: - faster on CPU-intensive tasks - more stably when processing large amounts of code - more safely in terms of memory leaks Linting and formatting are exactly CPU-heavy tasks, so Rust is an ideal choice. --- ### **2. A single high-performance parser** Biome uses **one shared parser** (for JS, TS, JSX, JSON, and so on). ESLint usually works like this: - connects an external parser (`@typescript-eslint/parser`) - this parser converts the code into an AST - then ESLint plugins read the AST - then ESLint rules traverse the AST again - then a separate tool, Prettier, re-parses the file - and traverses the AST again for formatting So the code is parsed **several times by different tools**. #### In Biome, it is the opposite: - one universal parser - one AST - one pass - minimal extra layers One pass over the tree instead of the 2-4 passes in ESLint/Prettier. --- ### **3. No dynamic plugin loading** ESLint is slow because: - it requires dozens of plugins - each plugin is a separate JS function - all of them are loaded and interpreted at startup Biome: - has almost everything built in - has no heavy plugin system (at this point) - rules are optimized at the compilation level Less JavaScript code → less IO → less interpretation. --- ### **4. Optimized AST traversal architecture** ESLint: - each rule walks the AST independently - rules often repeat each other's work - enabling 50+ rules creates 50+ traversals Biome: - performs a **centralized, optimized** tree traversal - uses static checks at the compilation stage - minimizes repeated traversals One traversal instead of many is a huge time saving. --- ### **5. No Node.js limitations** Node.js: - is slow on heavy computations - has single-threading limitations - suffers from the high cost of GC operations Biome: - uses Rust's capabilities for parallelism - works with memory directly - does not depend on V8 and its limitations Rust is better suited for intensive parsing and analysis tasks. --- ### **6. Minimal configuration = minimal work** ESLint: - even a basic configuration uses: - a parser - an Airbnb/Next/React config - linters for imports - linters for TS - integration with Prettier All of this is loaded and analyzed before startup. Biome: - one config - no third-party extensions besides core rules - optimization at the binary level Faster startup, less code, fewer layers. --- ### **7. The formatter is built in, not a separate process** Prettier is a separate tool. ESLint is a separate tool. They do not optimize each other's work in any way. Biome: - the formatter is part of a single engine - there is no extra work from re-parsing - there are no conflicts between the formatter and the linter 2 tools → 1 engine → 1 pass → faster.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.