Biome vs ESLint: Choosing Your Tooling
Cover photo by Zoe Richardson on Unsplash
So, you are sick of waiting for your linter to finish. I get it. I usually start a project by throwing in ESLint and Prettier because it is what I know.
The usual setup
Take this standard configuration:
{ "extends": ["eslint:recommended", "plugin:react/recommended"], "plugins": ["react"]}It works fine until the repository grows. Suddenly, checking your files feels like watching paint dry. This is where the naive approach breaks. You add more plugins to catch edge cases, and the performance penalty compounds. I’ve spent hours debugging slow rule execution, and honestly, it is not fun.
Enter Biome
Biome is fast. It is written in Rust, and it replaces both your linter and formatter. Here is how you might replace that bloated ESLint config with a single biome.json file:
{ "formatter": { "enabled": true }, "linter": { "enabled": true, "rules": { "recommended": true } }}It is incredibly fast (no, really, it is almost instant). It provides a unified experience without the “plugin hell” I often face in the ESLint ecosystem.
But wait
“What if I need custom plugins that Biome doesn’t support yet?” You’re right to ask. If you rely heavily on specific, niche ESLint plugins, moving to Biome is painful. You might lose functionality that isn’t ported. I have a few internal project configs that are still stuck on ESLint for this exact reason (though I am optimistic about the ecosystem catching up).
The trade-off
If you want the absolute best speed, Biome is a clear winner. If you need 100% compatibility with the massive library of existing ESLint rules, you should stay where you are. I think for most greenfield projects, Biome is the better default these days.
Are you willing to sacrifice some plugin flexibility for a faster terminal experience?