BiomeJS 2024 Roadmap | Hacker News Reader

BiomeJS 2024 Roadmap

biomejs.dev

67 pointsconaclos23 comments

> "Building a full-fledged type system such as TypeScript is a massive effort; that’s why we decided to take a different direction and start by building a subset of the type system that requires stricter typing."

I don't understand why they're building a type system when TypeScript exists, just to name one of great projects they mention.

Is there a manifesto somewhere that describes why this project is taking the high-risk path of boiling the ocean, instead of defining a set of best-in-class projects and improving integration over time? (The "Philosophy" page in the docs isn't helpful in this respect.)

For TypeScript specifically there is some justification in that the TypeScript compiler is rather slow, so any speed benefits of Biome would go away if it relied on TypeScript for type information.

But as a whole, not-invented-here syndrome has plagued Biome/Rome for the entire lifespan of the project. Like take a look at their error reporting code[1]. They made their own markup abstraction with their own Display trait and Write trait and a proc macro on top of it. It's cool code and probably does produce very nice error messages, but they could have easily used off the shelf crates like miette or ariadne and moved on to more important tasks.

Or even their JS parser. It's a really nice JS parser! Maybe the best in terms of error reporting and AST resolution. But they could have easily used swc and maybe shipped the actual end-user products a little faster.

[1]: https://github.com/biomejs/biome/blob/main/crates/biome_cons...

Originally, the project had a goal of zero dependencies. [1] I assume that was considered infeasible with the migration to Rust, but part of the philosophy remained.

[1]: http://web.archive.org/web/20201101030019/https://rome.tools...

Yeah...but why? Like zero-dependencies is one of those things that gets you praise on HN, but it means you spend a lot of time building...terminal console abstractions and not actually shipping stuff to users.

My understanding is that the zero-dependency approach was both 1) to require no transitive dependencies on install, compared to installing hundreds of packages to run some of the current standard JS tooling, and 2) to have maximum control over performance and size.

It’s an extreme approach that intended to get extreme results. One could definitely argue that you can get just good results with a good approach (like using a bundler to produce a single output, writing perf-sensitive code, continually testing for perf regression), that’s just not the path they chose from the start.

> Maybe the best in terms of error reporting

IMO this alone makes it worth it. The Rust compiler produces error messages that sit in a class of their own compared to almost everything else. I believe we should strive for more DX like that.

But miette already produces quite good error messages! On par with Rust's IMO: https://github.com/zkat/miette

I don't know anything about miette, but it didn't exist when Rome, the original code, was created (maybe it did exist but it was in its infancy, the two projects have the same age)

It definitely existed by the time rome_console/biome_console was created! The crate was created 2 years ago[1] and miette was released more than 2 years ago[2]. By the time rome_console was created miette was on v4, so presumably somewhat mature.

[1]: https://github.com/rome/tools/commits/main/crates/rome_conso...

[2]: https://crates.io/crates/miette/versions

Biome maintainer here.

The zero dependency philosophy concerns the legacy Rome JavaScript implementation. With the Rust rewrite, the Rome team was more open to add dependencies when it makes sense. I must admit that I don't know why they chose to implement their own console printer at the time.

The Rome community project (rebranded under the name "Biome") started one year ago, when the company failed. Only one core contributor comes from the Rome team. Others, including myself, joined the project at that time. Although we kept most of the Rome philosophy, we diverge from some of them. We are more open to the community: We implemented some of the most requested options (The Rome project was more hostile to add options). We are also more open to reuse existing solutions when it aligns with our primary goals.

I'll be honest, with the knowledge they are building their own type system and not adopting typescript, my interest went to near 0. Typescript has been a delight to use and migrating off of it is a non-starter. It will take a lot to get me to move off of using typescript even in greenfield projects.

I don't share your praise of typescript (native perf is terrible / it's not strict enough so I routinely get hit in production with type errors through the escape hatches) but you can very well use TS with Biome, I maintain a good number of TS services / apps using Biome and SWC (so I get decent performance).

Performance is also the reason I like Biome over eslint / prettier

I thought the same thing. Just another tool in the infinite list of tools in the JS ecosystem. No, thanks.

Why would you have to migrate off of TS?

Biome doesn't want to replace TypeScript.

I am also confused by this goal, I've started a discussion in the repo to get some clarity on intent and direction there: https://github.com/biomejs/biome/discussions/1642

Calling the TypeScript Compiler could slow down our linter making the switch from TypeScript ESlint to Biome less attractive. We don't aim to build a complete type system, just the minimal parts to be able to implement most of the linter rules that require type info. The idea is to build on the upcoming TypeScript Isolated Declarations [0]. If this is too much of work, then we will review our options.

[0] https://github.com/microsoft/TypeScript/issues/47947

Background on the project: https://biomejs.dev/blog/annoucing-biome/

The layout is broken on iOS Safari.

Who is adopting it?

I started using BiomeJS for a small personal project after reading that they won a Prettier bounty. I can say it is wicked fast! But, my project is very simple in scope so unfortunately I can't speak to concerns for large projects or migrating from prettier/eslint.

I use it for a very large monorepo to replace prettier. So much faster! Also have it run on save in my editor now.

Now linting full codebase on precommit and it’s faster than just linting staged files with prettier!

Good luck!

Reply on news.ycombinator.com