Why I Thought Biome Would Win

When I started evaluating alternatives, I was convinced that Biome would be my final choice.

At first glance, it seemed to solve almost every problem I had with my existing tooling.

compare biome and oxlint

It was incredibly fast, shipped with its own formatter, handled import organization, and aimed to replace multiple tools with a single executable. The idea of removing both ESLint and Prettier while simplifying the toolchain was extremely appealing.

More importantly, the developer experience felt polished. The documentation was easy to follow, the configuration was straightforward, and the overall philosophy of the project made a lot of sense.

If someone had asked me at that point which tool I was going to choose, my answer would almost certainly have been Biome.

Then I stopped reading documentation and started migrating a real project.

That’s when everything changed.

Speed Was Never the Real Challenge

Most comparisons between modern JavaScript linters focus almost entirely on benchmarks.

And to be fair, the performance improvements are impressive.

But once both candidates complete a full project lint in well under a second, another question becomes much more important:

Can this tool replace my existing workflow without forcing my team to change how they write code?

For me, performance was only the first filter.

Compatibility was the real evaluation.

I already had a mature ESLint configuration that had evolved over time. Every enabled rule represented an intentional decision. Some prevented bugs, others enforced consistency, and a few reflected coding conventions that the team had adopted over the years.

Migrating wasn’t simply about making the linter faster.

It was about preserving those decisions.

The Rule Compatibility Problem

This was where the biggest difference between the two tools started to appear.

Oxlint supports a large portion of the ESLint ecosystem, including many widely used React and TypeScript rules. During my migration, I was able to reproduce almost my entire ESLint configuration with only a few small adjustments.

Biome took a different approach.

Instead of aiming for complete ESLint compatibility, it provides its own curated rule set.

I actually like that philosophy.

A smaller, opinionated rule set makes configuration easier and reduces complexity.

The problem was that my project already depended on rules that simply didn’t exist in Biome.

Those missing rules weren’t obscure edge cases.

They were rules my team relied on every day.

That meant migrating to Biome would require changing coding standards, removing existing checks, or accepting behavioral differences.

None of those options felt right for an established codebase.

The Unexpected Import Sorting Challenge

One of the most interesting problems I encountered involved import sorting.

In my ESLint setup, import ordering was enforced by a dedicated lint rule with a customized configuration.

Naturally, I expected to configure the same behavior in whichever tool I chose.

Instead, I discovered that both tools approached the problem differently.

Biome includes import organization as part of its tooling, but its configuration options were simpler than what I needed.

Oxlint, on the other hand, doesn’t treat import sorting as a linting rule at all.

Instead, import organization belongs to Oxfmt, the formatter.

At first, I considered this a disadvantage.

Why move something from the linter into the formatter?

After experimenting with it, though, my perspective changed.

The formatter was capable of producing nearly the same import ordering that my ESLint setup enforced, while also replacing Prettier entirely.

Rather than seeing it as a missing feature, I started seeing it as a different architectural decision.

Linting was responsible for correctness.

Formatting was responsible for code layout.

Once I embraced that separation, the overall workflow actually felt cleaner.

Auto Migration Is Only the Starting Point

Both Oxlint and Biome provide commands to migrate an existing ESLint configuration automatically.

These tools do an impressive job of generating an initial configuration, but they shouldn’t be treated as the finish line.

For my migration, I used Oxlint’s automatic migration tool to bootstrap the configuration.

Then I manually reviewed every migrated rule.

Some rules required small adjustments.

Others had equivalent implementations under different names.

And a few formatting-related rules were better handled by Oxfmt instead of the linter itself.

That manual review turned out to be one of the most valuable parts of the migration.

It helped me understand exactly how the new tool behaved instead of blindly trusting an automated conversion.

My Decision Started to Change

By the end of my research, the comparison no longer looked like this:

ToolSpeedBiomeSlightly FasterOxlintVery Fast

Instead, it looked like this:

Biome was still an excellent tool.

If I were starting a brand-new project from scratch, I would seriously consider using it.

But I wasn’t starting from scratch.

I was migrating a mature project with an established linting strategy.

For that scenario, preserving existing behavior mattered far more than saving a few extra milliseconds.

And that was the moment Oxlint became the clear choice.