One tool for how code looks and how code behaves

A frontend project has traditionally needed two kinds of machinery. One keeps the shape consistent, wrapping lines and ordering imports; the other keeps the meaning honest, flagging unused variables and suspicious conditions. In practice that meant two packages, two configuration files, two editor extensions, two sets of errors with different formats, and a permanent invitation for the two to disagree about the same line. Biome merges them into a single binary that formats and lints, installs once, and reads one configuration file.

The lineage matters for understanding the ambition. It continues the idea of a unified toolchain that an earlier project proposed and never finished shipping, and the community picked up the concept with a much shorter path from announcement to a usable release. The philosophy survived; the delivery did not stall.

The speed is not a marketing number

The engine is written in Rust, and the practical consequence is that formatting on save is genuinely instant, with no perceptible pause between the keystroke and the file being rewritten. A full check of a large repository finishes in seconds rather than in the time it takes to make coffee, which changes behaviour: you run it constantly instead of saving it for a commit. Continuous integration times drop in a way that is easy to measure and hard to argue with.

Compatibility received similar attention. Output aims to match the established de facto formatter closely enough that migrating an existing codebase is closer to a swap than a rewrite, and the diff noise from a first run is small enough that reviewers can actually read it. That detail decides adoption more than any feature list, because a migration that produces ten thousand unrelated changes will be rejected regardless of how fast the tool is.

The rule set keeps growing, and framework-specific checks have been arriving steadily. Diagnostics are reported with the source span, a suggested fix and a stable rule name, which matters for teams that suppress rules deliberately and want the suppression to survive an upgrade. Editor integration exists for the mainstream editors, and the language server behaves like a modern one rather than a syntax highlighter with opinions.

Where it is not the obvious answer

Projects with a heavily customised lint setup, dozens of community plugins and rules written in-house will find gaps, and rewriting those rules is real work. Very old codebases, or ones with unusual file layouts, may need configuration that the tool does not yet express comfortably. And if a team is happily standardised on the older pair of tools with no complaints, switching costs more than it returns.

For new projects the calculation is different: there is nothing to migrate, the configuration is one short file, and the default rule set is a sane starting point rather than a list that needs pruning before it is useful. That is the case this tool was designed around, and it is a large share of the projects started this year.

Biome points at where frontend tooling is converging. Rather than ask developers to maintain a pile of small tools with their own opinions, give them one implementation that is fast and good, and hand the time back to writing code.

How to adopt it without drama. In a new project, start from the defaults and commit the configuration on day one so nobody argues about style in review. In an existing project, migrate formatting first, land that as a single mechanical commit that reviewers can skip, then enable lint rules gradually and fix them per directory rather than all at once. Put an incremental check in continuous integration so the debt does not grow back, and suppress rules with a comment and a reason rather than disabling whole categories.

A final note on discipline: the value of a formatter is that nobody discusses formatting. If the tool is in place but the team still debates line length in pull requests, the technical part is solved and the social part is not.