developer tooling opinions

the case for fewer tools

every tool in your stack is a thing that can break, a thing that needs updating, and a thing that new team members need to learn. the javascript ecosystem has a habit of solving one problem with three tools and a plugin system.

i used to run eslint + prettier + separate configs for each. it worked, but it was slow, the configs conflicted occasionally, and debugging formatting issues was never fun.

biome

biome replaces both eslint and prettier with a single binary. it’s fast — noticeably fast, not just benchmarks-fast. it formats and lints in one pass. the defaults are sensible. configuration is minimal.

the trade-off is fewer rules and less ecosystem coverage than eslint. but honestly, most eslint plugins i used were enforcing opinions i could just as easily enforce through code review. the rules that matter — no unused variables, consistent imports, basic correctness checks — biome handles well.

for this site i use: single quotes, always semicolons, 2-space indent. that’s basically the entire config.

what about prettier?

prettier is fine. i’m not anti-prettier. but running two tools to do what one tool can do faster doesn’t make sense to me. if you’re starting a new project, try biome first.

the broader picture

the trend toward rust-based tooling (biome, oxlint, rspack) is good for the ecosystem. faster tools mean tighter feedback loops. tighter feedback loops mean more iteration. more iteration means better software.

i don’t think we need to rewrite everything in rust. but the tools that run on every save, every commit, every ci pipeline — those are worth optimizing.

what i’m watching

• oxlint — if it gets plugin support, it could be interesting as a biome alternative
• deno and bun — both trying to collapse the toolchain. deno’s approach of including a formatter, linter, and test runner in the runtime is compelling
• astro — keeps getting better at the thing it does well: content-driven sites with minimal client js