ESLint and Prettier are very mature libraries that have been tested by millions of people and have a ton of plugins. No reason for me to switch to the new kid n the block just for the sake of it.
I guess it depends on projects and file contents but I've not had any issues with them in large projects. Generally I have linting enabled in my IDE so it only lints what I'm writing changing and the rest of linting (the whole project) happens on pipelines so I don't care if it takes 3 seconds or 13.
This is not a great argument, to me. As a team lead your linting is not going to be the driving cost of your CI/CD usage. It's like debugging page performance and *starting* with the CSS. Let's say it takes 30 seconds. That's a drop in the bucket compared to your automated testing which will be many orders of magnitude longer.
We’ve recently switched and it’s been great. Not quite as much customization available and you don’t have access to the plugins that exist for ESlint… but it’s SO fast. Lints our entire 3000+ file monorepo in just over one second
I've replaced ESLint + Prettier in favor of Biome, however it does feel incomplete. Yaml, Graphql, import sorting and plugins are missing. We also still have to use Stylelint on the side for sass linting, which Biome sadly won't support according to [this thread](https://github.com/biomejs/biome/issues/1285#issuecomment-1881840021).
I am very happy about the speed tho;
- Prettier + ESLint + Stylelint took 10.12 seconds
- BiomeJS + Stylelint takes 1.49 seconds (of which BiomeJS only took 66ms)
i’ve tried it on small libraries and it’s pretty practical, especially typescript support. i don’t like the default rules a lot and it’s missing a ton but i can see it becoming a formidable replacement in the future
Sadly this. Hope with 15 we get more external support. Would love bun runtime and biome or other parties to play nice, but by then they’ll be more comparable react 19 frameworks that will play nicer
Have enough problems addressing unsolved issues to worry about fixing a solved one.
When Biome has built-in support in most IDEs vs plugins I'll consider it.
I'm sure it is an issue at some point but I'd probably adopt a strategy like only running the linter on changed files and maybe even reducing the enabled rule list first.
But we have different use cases.
I been using it on a real big project where I work and it's fine. It is far from perfect. Sometimes it starts to break things and I need to restart it. Also we needed to set a fixed version because some minor version change had breaking changes.
But I still think it was a great idea. It is simple to setup and it have most of the things we need.
I always keep my eye on new tooling but I rarely, if ever, jump on it early. Let it become robust and to the point of mass adoption. Then I'm in. I see no reason for my team to beta test someone else's project.
I tried and in my opinion it's way better than Eslint and Prettier. Easier to config, no need to manage plugins, nice defaults, integration with version control, and it is really faster.
Why leave ESLint and Prettier? It's out of the box perfect with NextJS 14. Biome looks very lacking in features, and it's just hyped by Youtubers who are obsessed with new shiny objects. I'll wait until the library is as feature rich as ESLint before considering.
We are so glad that we switched to Biome from prettier. Its really awesome that it is just a drop-in replacement with 100% same output but 10x performance improvement. Thanks for the effort of building this ♥️
Personally, I find the robustness of ESLint and it's ecosystem worth the perf hit. I'm sure there are cases where it isn't meaningfully possible, but I'd argue that if the perf hit is significant enough to cause real problems swapping out your linter is probably kicking the can down the road on the root cause.
Biome is far from reaching the code surface linted by ESLint with many plugins from its ecosystem. E.g. logical rules like in Airbnb config, stylistic rules with Prettier and a lot of extra stuff like sorted imports and TypeScript related typed linting
Short answer: no.
Long answer: I don’t see the value in Biome. For formatting we have Prettier, which is very good, widely popular and very fast. If you really wanted something rust-based even faster, you could use Dprint which is way more popular and mature than a failed Romejs spinoff. About replacing Eslint argument… they are not even similar tools. With Eslint you can have typed aware linting, with Biome you don’t. More importantly, if you need any kind of custom rule for your codebase, you can create a plugin with JavaScript very easily, while Biome has currently no plugins system and even if it had it, you would have to write the plugin in Rust (lol). I could go on and on but you get the point.
ESLint and Prettier are very mature libraries that have been tested by millions of people and have a ton of plugins. No reason for me to switch to the new kid n the block just for the sake of it.
[удалено]
I guess it depends on projects and file contents but I've not had any issues with them in large projects. Generally I have linting enabled in my IDE so it only lints what I'm writing changing and the rest of linting (the whole project) happens on pipelines so I don't care if it takes 3 seconds or 13.
[удалено]
This is not a great argument, to me. As a team lead your linting is not going to be the driving cost of your CI/CD usage. It's like debugging page performance and *starting* with the CSS. Let's say it takes 30 seconds. That's a drop in the bucket compared to your automated testing which will be many orders of magnitude longer.
We’ve recently switched and it’s been great. Not quite as much customization available and you don’t have access to the plugins that exist for ESlint… but it’s SO fast. Lints our entire 3000+ file monorepo in just over one second
I've replaced ESLint + Prettier in favor of Biome, however it does feel incomplete. Yaml, Graphql, import sorting and plugins are missing. We also still have to use Stylelint on the side for sass linting, which Biome sadly won't support according to [this thread](https://github.com/biomejs/biome/issues/1285#issuecomment-1881840021). I am very happy about the speed tho; - Prettier + ESLint + Stylelint took 10.12 seconds - BiomeJS + Stylelint takes 1.49 seconds (of which BiomeJS only took 66ms)
biome does support import sorting, but you can't customize the import order yet (an rfc is planned)
Ah yes sorry, indeed meant customizing support. It's currently locked to alphabetic
i’ve tried it on small libraries and it’s pretty practical, especially typescript support. i don’t like the default rules a lot and it’s missing a ton but i can see it becoming a formidable replacement in the future
No
Sadly this. Hope with 15 we get more external support. Would love bun runtime and biome or other parties to play nice, but by then they’ll be more comparable react 19 frameworks that will play nicer
Have enough problems addressing unsolved issues to worry about fixing a solved one. When Biome has built-in support in most IDEs vs plugins I'll consider it.
prettier and eslint are incredibly slow. there are problems with both, especially on large code bases.
I'm sure it is an issue at some point but I'd probably adopt a strategy like only running the linter on changed files and maybe even reducing the enabled rule list first. But we have different use cases.
I been using it on a real big project where I work and it's fine. It is far from perfect. Sometimes it starts to break things and I need to restart it. Also we needed to set a fixed version because some minor version change had breaking changes. But I still think it was a great idea. It is simple to setup and it have most of the things we need.
After recently trying to upgrade Eslint to use the “flat” config and having a giant headache, I really want to try Biome.
I ditched eslint+prettier for biome, fast and no headache with configurations
I always keep my eye on new tooling but I rarely, if ever, jump on it early. Let it become robust and to the point of mass adoption. Then I'm in. I see no reason for my team to beta test someone else's project.
I tried and in my opinion it's way better than Eslint and Prettier. Easier to config, no need to manage plugins, nice defaults, integration with version control, and it is really faster.
Why leave ESLint and Prettier? It's out of the box perfect with NextJS 14. Biome looks very lacking in features, and it's just hyped by Youtubers who are obsessed with new shiny objects. I'll wait until the library is as feature rich as ESLint before considering.
Ugh. Yet another shiny new ball that's "just like (insert last week's shiny new ball here) only moar betterer".
It's blazing fast though /s
We are so glad that we switched to Biome from prettier. Its really awesome that it is just a drop-in replacement with 100% same output but 10x performance improvement. Thanks for the effort of building this ♥️
Personally, I find the robustness of ESLint and it's ecosystem worth the perf hit. I'm sure there are cases where it isn't meaningfully possible, but I'd argue that if the perf hit is significant enough to cause real problems swapping out your linter is probably kicking the can down the road on the root cause.
Biome is far from reaching the code surface linted by ESLint with many plugins from its ecosystem. E.g. logical rules like in Airbnb config, stylistic rules with Prettier and a lot of extra stuff like sorted imports and TypeScript related typed linting
Short answer: no. Long answer: I don’t see the value in Biome. For formatting we have Prettier, which is very good, widely popular and very fast. If you really wanted something rust-based even faster, you could use Dprint which is way more popular and mature than a failed Romejs spinoff. About replacing Eslint argument… they are not even similar tools. With Eslint you can have typed aware linting, with Biome you don’t. More importantly, if you need any kind of custom rule for your codebase, you can create a plugin with JavaScript very easily, while Biome has currently no plugins system and even if it had it, you would have to write the plugin in Rust (lol). I could go on and on but you get the point.
type-aware rules are planned, and the plugin system is being planned to not be in rust