Is Biome ready to replace Prettier & ESLint?
Introduction
The emergence of new languages like Rust and Zig offers modern solutions to the security and performance issues encountered with JavaScript. These languages not only address critical system-level concerns but also enhance the development experience through advanced tools and features. Their growing adoption in the JS ecosystem highlights a shift towards more robust, efficient, and developer-friendly environments, paving the way for the next generation of high-performance applications.
It is in this context that, two years ago, Biome was put in the spotlight when it won a $25.000 prize for the creation of a Prettier alternative as a formatter tool, proving to be compatible with most of its rules already.
This prize shows that a new need is emerging for the formatting and linting ecosystem. In hope for a friendly competition, Christopher Chedeau (cofounder of Prettier) initiated this bounty to push forward the evolution of these tools; and it soon was joined by other actors such as Guillermo Rauch (Vercel’s CEO), Wasmer.io and NAPI-RS.
Even though Prettier and ESLint cover most of the needs as formatter and linter, technologies progress fast and unlock more efficient solutions as time goes by. Our apps are increasingly heavy, meaning that optimizing every part of the toolchain is crucial, and still appreciated in local development.
Biome is not the first to emerge in this space. It builds upon an older project called Rome, whose holding company shut down, and it faces existing competitors. OXC is one of these competitors, and we will include it in our analysis as it is also built with Rust.
Biome has become a challenger on two fronts: linting and formatting. Based on Rust, its native execution ensures performances that its competitors cannot yet hope to match.
Features
Two in one: Linting & Formatting
Because both tools rule over the code quality, having a combined configuration file feels natural. Biome makes it seamless to coordinate the tools, set up the development environment and ensure everyone follows the same code format at any moment.
To make it easier, Biome comes with a default set of rules that you can activate through a simple “rules.recommended: true” in the configuration file. It is even possible to migrate from Prettier and ESLint using commands that will generate your Biome configuration file by analyzing your existing linter and formatter ones!
Most of the rules, more selective
While Biome aims to be an easy replacement for Prettier and ESLint by being compatible with most of the rules, it will not implement all of them in the long run. The Biome team has stated that some rules will not be implemented because of inconsistencies or to follow the evolutions in the JavaScript ecosystem.
Even though the plugin system is not finished as of today, Biome is open to integrating new rules and even began to work on popular rules from plugins of its competitors.
Easier to work with
Error messages and the documentation are meant to be as easily understandable as possible when using Biome. Key points are being verbose and avoiding jargon and abbreviations, but also avoiding generalizations in profit for tailor made specific messages.
This result is part of the difference in conception Biome has chosen. While many parsing tools use Abstract Syntax Trees (AST) to analyze the code, Biome’s parser uses a Concrete Syntax Tree (CST) which contains more in-depth details of the code.
VCS Integration
While ESLint and Prettier have built-in optimizations, such as caching mechanisms and file ignoring based on .gitignore, their capabilities are somewhat limited when it comes to dynamic VCS awareness. ESLint offers a caching feature that tracks file modification timestamps to avoid re-linting unchanged files, and developers often use tools like lint-staged to apply Prettier only to staged files. These optimizations help improve performance, especially in larger projects.
However, Biome takes this a step further. Not only does it incorporate similar caching mechanisms, but it also integrates natively with VCS, providing a smarter, more efficient workflow. Biome can detect file changes directly from the VCS, allowing it to process only the files that have been modified in the current branch or commit. This VCS-aware capability eliminates the need for additional tools like lint-staged, simplifies configuration, and ensures that linting and formatting operations are both faster and more accurate.
The advantage becomes even more apparent in large repositories where branch switching and frequent commits can render traditional caches ineffective. While ESLint’s cache may become stale in such scenarios, Biome’s VCS integration ensures consistent performance without manual cache invalidation. This makes Biome particularly well-suited for modern CI/CD pipelines and large-scale monorepos.
Powered by Rust
To achieve important levels of performance, modern JavaScript ecosystems use external libraries powered by Zig or Rust. Both are natively executed, which not only brings performance and is less dependent on its environment, but also means better security, making them the perfect candidates for tools and performance heavy functionalities. Biome and OXC are part of this new generation of tools, using Rust at their core.
More about OXC
OXC describes itself as a toolbox; it does not only aim to lint and format, but also to bring many other high-performance tools including a parser, a resolver, and a transformer. This can come in handy in pipelines where precise technical tasks are needed and have already proven useful to Biome as it currently uses OXC’s resolver.
Compatibility
Being specialized in the JavaScript ecosystem, Biome supports a limited set of languages at the time. This includes ES2024 for JavaScript, TypeScript 5.6, CSS, JSON, but also some derivatives like JSX, with some more planned or in the works such as HTML and Markdown.
If part of your codebase is written in a non-supported language, you will need to install another linter and formatter along with Biome, or instead of it to avoid the hassle of configuring them so they can work together.
Including Biome in your project should come without hassle in small projects as it is natively compliant with 97% of the rules ESLint brings and popular rules from other sources. While an impressive feat, the absence of plugins (to this day) can mean that some specific, but sometimes essential, rules will not be available.
Slight changes might appear in your codebase as outdated rules and inconsistencies are addressed when it comes to formatting. This is because the Biome team re-examines the rules with a fresh eye and their own philosophy.
Our observations lead to the lack of support for some technologies, which will put a stop to its integration into bigger projects. For instance, GritQL (a query language designed for flexible data fetching) is still at an experimental stage along with few languages such as YAML, and monorepo support is limited at the time, rendering a range of projects incompatible.
Biome integrates easily in well-known IDEs such as VS Code, IntelliJ, or Zed and a few more as third-party extensions (Vim, Neovim, Helix). The documentation explains how to add your preferred IDE if it is missing, showing how easy it is to use its command line in any environment.
Speaking of CLI, Biome is ready to be integrated in a CI/CD process. It comes with an official GitHub Action and third parties developed another Action which can comment (or commit) on pull requests using reviewdog.
As for the direct competition, OXC does not feature a formatter, and the team recommends the use of their linter only for specific cases when others are deemed too slow for the workflow.
OXC’s compatibility with languages is more limited (only supporting JS based languages), but it features a CLI and a few IDEs extensions (Visual Studio Code and Zed). To make up for the lower set of rules adapted from ESLint, a package is published to enable both linters in your project by turning off ESLint where OXC is compatible.
Performances
It is precisely in integration and delivery steps that Biome’s impact is the most appreciated. Even if developers will benefit from faster linting and formatting, it is usually a matter of a few hundred milliseconds. The integration though parses through many files, multiplying the impact of the performance increase.
Since Biome is built in Rust, it benefits from being compiled directly to machine code, allowing it to execute significantly faster than JavaScript-based tools. Rust is widely recognized for enabling the creation of highly optimized and memory-safe programs, which helps Biome achieve faster processing speeds while maintaining reliable performance.
Another important factor contributing to Biome’s performance is its use of Concrete Syntax Trees (CST) instead of the more commonly used Abstract Syntax Trees (AST).
AST is optimized for core compilation tasks like semantic analysis and code optimisation. It simplifies the code structure by removing unnecessary syntactic details, making it faster and more efficient for these operations. On the other hand, the CST retains all syntactic elements, such as parentheses, keywords, and formatting details. While this makes it heavier and less efficient for core compilation processes, it’s highly valuable for auxiliary tasks like code formatting, static analysis, and building intelligent code editors, where a detailed representation of the source code is essential.
The Biome team promises an increase of up to 15x compared to ESLint, and up to 25x compared to Prettier. Launching the official benchmark ourselves, we have been able to confirm the effective speed of the linting and formatting (24x times faster than Prettier and 22x times faster than ESLint):
As part of our ongoing benchmarking tests, we used Biome on internal ekino projects. For example, on large projects, the performance difference between Biome and Prettier is significant. Replacing Prettier with Biome for formatting showed:
On another set of tests conducted on a different internal project, a giant monorepo containing more than twenty APIs, we obtained additional interesting results demonstrating Biome’s superiority in terms of speed compared to Prettier and ESLint when no cache is available:
Biome’s performances versus Prettier and ESLint on small projects
For small projects, performance gains are less critical, but Biome’s simplicity stands out. Replacing ESLint and Prettier with Biome reduces dependencies and simplifies configuration. It is particularly attractive for projects with minimal ESLint plugin usage.
On the OXC’ side
We can observe from OXC’s official benchmarks that it is 1.02 times faster than Biome and 2.67 times faster than ESLint on the linter part:
While performance may not be the primary consideration when choosing a formatter or linter, faster execution is certainly a welcome bonus. This advantage can only be positive, adding a little extra efficiency, especially in larger codebases — or even just for quicker initialization when opening our IDE or a file.
Long term & Stability Project
To keep the improvements going, big projects like these need to be stable eventually. Once the rush of first release and proof of concept is gone, new motivators must be found and, in our era, this necessarily comes with some form of compensation for the team. Biome has set up efficient methods to generate revenue and cover its costs.
This includes utilizing GitHub’s native sponsorship system, enabling donations from various sources, be it individuals or organizations. This is also the main visible source of revenue for OXC.
Both projects feature a OpenCollective page, a powerful financial tool which facilitates financial contributions and consolidates revenues from other sources. While Biome’s page is very complete and shows an annual budget of nearly $32,000, OXC’s page is still in its early setup.
These pages ensure transparency by showing where the funds they earn go, to whom and for which purpose. Additionally, it provides a visual representation of the economic model behind the open-source project.
Finally, Biome integrates Polar.sh, which offers to compensate open-source contributors for specific tasks, thereby prioritizing the development of the most requested features through financial incentives. As of the time of drafting this article, the support for the monorepo has been funded with $1,000 contributed to complete this feature.
With all these tools combined, Biome proves to take the matter very seriously. Its budget of $32,000 may seem low compared to ESLint ($191,000 annual budget) and Prettier ($57,000 annual budget), especially when it aims to compete with both, but still shows the hype the project has been able to gather in a bit more than a year of existence.
While Prettier and ESLint are stable, Biome and OXC still need to catch up; and that is what is happening. Both have maintained high activity levels these past months, unlocking new releases and fixes regularly. Over the span of a month, Biome received 159 commits totaling 170,000 changes and OXC does not fall short with of it with 571 commits and 110,000 changes. This is very impressive compared to Prettier (22,000 changes) and ESLint (2,000 changes) but remember that these do not need as much care.
TSLint died, will Biome too?
Although we cannot predict the future, Biome was created with a clear understanding of ESLint’s dominance in the ecosystem, recognizing that ESLint already supports TypeScript and benefits from a large, active community. Unlike TSLint, which initially aimed to provide a TypeScript-specific solution but later faced challenges adapting to the evolving landscape, Biome enters the scene with a competitive mindset. It positions itself as a direct challenger to ESLint by offering an all-in-one high-performance solution with linting, formatting, and bundling capabilities, leveraging Rust for speed and efficiency. This strategic approach indicates that Biome is fully aware of the competition and aims to differentiate itself from the outset, rather than evolving in response to market demands over time.
Conclusion
Biome and OXC are quite new in the open-source world. Born from developers’ frustration and ambition, these tools aim to push the limits of performance and developer experience. With modern features, they strive to outshine established tools like ESLint and Prettier. However, as Biome and OXC bring fresh energy and innovation, it is likely that ESLint and Prettier will respond. Improving performance and developer experience is a shared goal for everyone in open source. This has sparked a healthy cycle of competition between Biome/OXC and ESLint/Prettier. Each will learn from the other’s ideas, leading to positive changes across the board.
Based on our tests at ekino, along with statements from Biome and OXC themselves, some aspects of these tools are still not fully stable or compatible with current rules and environments. This makes them less suitable for critical production environments, where migrating style or formatting rules could be incompatible or too complex.
ESLint and Prettier remain top choices for any project while Biome and OXC, still young and incomplete, provide a good alternative for small projects and developers in search of lightweight linting and formatting. These new competitors bring fresh air and are already shaking the ecosystem. Progressing at this rate, they will play a leading role in the coming years and will open the way to new sets of developer experience tools.
Additionally, Biome 2.0 will bring plugin support, enhanced monorepo management, and multi-file linting. The 2025 roadmap includes HTML support, embedded languages, and advanced type-based linting, reinforcing Biome’s commitment to performance and innovation. An exciting future lies ahead!
For more updates, visit ekino’s website and follow us on LinkedIn.
