[HN Gopher] BiomeJS 2024 Roadmap
___________________________________________________________________
BiomeJS 2024 Roadmap
Author : conaclos
Score : 56 points
Date : 2024-01-22 13:52 UTC (9 hours ago)
(HTM) web link (biomejs.dev)
(TXT) w3m dump (biomejs.dev)
| CharlesW wrote:
| > _" 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.)
| wrongcarwhy wrote:
| 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...
| cjpearson wrote:
| 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.t
| ools...
| wrongcarwhy wrote:
| 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.
| JasonSage wrote:
| 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.
| tomashubelbauer wrote:
| > 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.
| wrongcarwhy wrote:
| But miette already produces quite good error messages! On
| par with Rust's IMO: https://github.com/zkat/miette
| riquito wrote:
| 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)
| wrongcarwhy wrote:
| 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/ro
| me_conso...
|
| [2]: https://crates.io/crates/miette/versions
| conaclos wrote:
| 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.
| Dibes wrote:
| 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.
| jokethrowaway wrote:
| 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
| gabrieledarrigo wrote:
| I thought the same thing. Just another tool in the infinite
| list of tools in the JS ecosystem. No, thanks.
| steezeburger wrote:
| Why would you have to migrate off of TS?
| conaclos wrote:
| Biome doesn't want to replace TypeScript.
| orpheansodality wrote:
| 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
| conaclos wrote:
| 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
| continuational wrote:
| The layout is broken on iOS Safari.
| eviks wrote:
| Good luck!
| ushakov wrote:
| Who is adopting it?
| ericyd wrote:
| 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.
| atjoslin wrote:
| 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!
| senkora wrote:
| Background on the project: https://biomejs.dev/blog/annoucing-
| biome/
___________________________________________________________________
(page generated 2024-01-22 23:01 UTC)