4 ms·

If I understand it right, we have 3 large projects that aim to replace most of JS tools on their own: Bun[0], Oxc[1] and Biome[2]. Bun's package manager is grea

If I understand it right, we have 3 large projects that aim to replace most of JS tools on their own: Bun[0], Oxc[1] and Biome[2]. Bun's package manager is great, Biome formatter recently reached 96% compatibility with Prettier, and now Oxlint is apparently good enough to replace ESLint at Shopify. Exciting times ahead. But it's giving the impression that these projects perhaps could be better off collaborating instead of each of them aiming to eat the world on their own? EDIT: I'm not saying it's wrong to write competing tools, it's open source anyway, so please do whatever you like with your time and have fun. But it looks like out of these 3 projects, 1 has a startup behind it, and 1 receives funding from bigger company. I assume that money will stop coming in if these tools don't gain adoption fast enough, and nobody would want to see that happen, especially with so much potential here. [0] https://bun.sh/ https://bun.sh/ [1] https://oxc-project.github.io/ https://oxc-project.github.io/ [2] https://biomejs.dev/ https://biomejs.dev/

djbusby 3y ago
Happens loads of times. There is some in-built human condition that folk basically see a thing that they could improve but then decide to go off and build their own moon-base rather than work on someone elses project.
- throwaway894345 3y ago
  In my experience, project maintainers are frequently uninterested in changes to their project, especially if those changes are a significant departure from their current vision or if it involves pivoting away from tools that they like. You're often expected to make years of contributions to the project to earn the rapport to bring significant suggestions before the maintainers. It's often just easier to 'build your own moonbase' instead of politicking. Just a couple days ago, the curl maintainer published a blog post about why he wouldn't rewrite curl in Rust and a big part of the reason was that he and the other maintainers weren't good at it and weren't the right people to lead a project that used it--he said that he encouraged other people to start their own project in Rust. But then when people follow that advise, they're chided for not contributing to the more established project! To be clear, I'm not a "just rewrite it in Rust" guy, but I think people underestimate the difficulty and frustration involved in petitioning an established project to make the reforms necessary for significant improvements.
- vintermann 3y ago
  Well, when they pretty much succeed at building their moon base, I say good on them.
  - bluGill 3y ago
    Except that this is not as good as the original by their own admittance. If they had collaborated they could likely get more done in the same amount of time. (not twice as much, but more) Maybe this is a better design than the other projects. Maybe people cannot get along and so they are forced to fork. There are many other good reasons to not contribute to an existing project. However we should always look at skepticism on such claims: it is easy to start you own project and you are in control so the amount of work you get done is higher. However working together, while it makes everyone slower normally results in many more features and higher quality code over the long term. So please when you have an itch technology can solve look to see if you can contribute to someone else's project first. It won't be as fun, but the world and you will be better for it.
wg0 3y ago
More like JS folks are discovering compiled languages. Now instead of a new JS framework daily, it's going to be new reimplementation of an existing tool daily. For a while.
- shzhdbi09gv8ioi 3y ago
  About time, js cli apps were never a good idea.
  - maccard 3y ago
    They exist because it's significantly easier to distribute js apps than it is to distribute a compiled app. npm install works on Linux, Mac and windows, regardless of what libc, Msys, crt, you have installed. It could be python, but pip is a usability nightmare
    - boredumb 3y ago
      Not particularly true especially in this case. You can get a rust binary and run it anywhere regardless of libc or having cargo installed on the users machine. A Javascript CLI requires nodejs and npm to be installed before running it.
      - rob74 3y ago
        Same goes for Go BTW. I even find it easier to install Go (haven't done it for Rust that often yet) and compile a binary (of a "pure" project that doesn't involve C libraries or other complications) than installing node/npm/nvm/whatever to get something up and running...
      - maccard 3y ago
        In this particular case, you wouldn't be installing oxlint unless you had npm installed already?
        boredumb 3y ago
PoignardAzur 3y ago
There's also Deno: https://deno.com/ https://deno.com/
pzmarzly 3y ago
To clarify: I'm also not advocating for merging the codebases together, that would be mostly counterproductive (especially since Bun is in Zig, and Oxc and Biome in Rust). When I think why Rust was successful at establishing community-accepted standard tooling (clippy, rust-lsp), 2 things come to mind: - Project developers were always promoting each other's tools, pointing them out in docs or blog posts - Good tools were being pulled into rust-lang GH org (for visibility) and rustup CLI distribution (for ease of system-wide installation) Both of these things are not technical challenges, they are rather more "political" (require agreements between parties). In JS ecosystem, what would it take for Oxc to say on their website "we are not writing a formatter, please install Biome" and for Biome homepage to say "we are not writing a linter, please install Oxlint"?
- thatxliner 3y ago
  Except Biome can also function as a linter
- conaclos 3y ago
  Biome is the continuation of Rome Tools. It exists since several years and always featured a linter and a formatter. If I remember correctly, OXC was born out of its author's desire to learn Rust and his feeling that Rome Tools/Biome had made complex technological decisions (mainly the use of CST instead of an AST). Rome Tools/Biome chose a CST to bring first-class IDE support: you can format and lint malformed code as you are writing it. I hope more collaboration between Biome and OXC in the future. However, the inherent difference comes from technological choices.
conartist6 3y ago
[3] https://github.com/bablr-lang https://github.com/bablr-lang I'm its author and focus solely on the collaboration picture. I don't generate much press because I only build internal APIs for tooling and language authors, where the projects you've shared all opted to prioritize fulfilling specific real use cases over generalizing their core technology. Cruel as it is, I think all of them have planted the seeds of their own failure by failing to protect their organization's mission and day-to-day work from being jailed by a set of specific opinions about code style, which cannot possibly be "right" or "wrong" but must instead by argued about forever. I see the core challenge as shifting all editors and tools to share a common DOM representation and be interoperable in a per-node way, where the current solution is to use siloed and reimplemented tools which interoperate mostly in a per-file way, with each tool parsing the text, doing some work, then emitting text for some other tool to parse...
- conartist6 3y ago
  For example: "The Oxc AST differs slightly from the estree AST by removing ambiguous nodes and introducing distinct types. For example, instead of using a generic estree Identifier, the Oxc AST provides specific types such as BindingIdentifier, IdentifierReference, and IdentifierName." Already this is getting into matters of style! It is one style, yes, but Javascript's shorthand syntax `({ foo })` already breaks the mental model: the identifier `foo` is technically doing the work of both an IdentifierName and an IdentifierReference. OXC chooses IdentifierReference so any system built on top of it would need to contain additional logic in order to be able to identify all sites in code that are used as identifier names.

djbusby 3y ago

Happens loads of times. There is some in-built human condition that folk basically see a thing that they could improve but then decide to go off and build their own moon-base rather than work on someone elses project.

throwaway894345 3y ago
In my experience, project maintainers are frequently uninterested in changes to their project, especially if those changes are a significant departure from their current vision or if it involves pivoting away from tools that they like. You're often expected to make years of contributions to the project to earn the rapport to bring significant suggestions before the maintainers. It's often just easier to 'build your own moonbase' instead of politicking. Just a couple days ago, the curl maintainer published a blog post about why he wouldn't rewrite curl in Rust and a big part of the reason was that he and the other maintainers weren't good at it and weren't the right people to lead a project that used it--he said that he encouraged other people to start their own project in Rust. But then when people follow that advise, they're chided for not contributing to the more established project! To be clear, I'm not a "just rewrite it in Rust" guy, but I think people underestimate the difficulty and frustration involved in petitioning an established project to make the reforms necessary for significant improvements.
vintermann 3y ago
Well, when they pretty much succeed at building their moon base, I say good on them.
- bluGill 3y ago
  Except that this is not as good as the original by their own admittance. If they had collaborated they could likely get more done in the same amount of time. (not twice as much, but more) Maybe this is a better design than the other projects. Maybe people cannot get along and so they are forced to fork. There are many other good reasons to not contribute to an existing project. However we should always look at skepticism on such claims: it is easy to start you own project and you are in control so the amount of work you get done is higher. However working together, while it makes everyone slower normally results in many more features and higher quality code over the long term. So please when you have an itch technology can solve look to see if you can contribute to someone else's project first. It won't be as fun, but the world and you will be better for it.

wg0 3y ago

More like JS folks are discovering compiled languages. Now instead of a new JS framework daily, it's going to be new reimplementation of an existing tool daily. For a while.

shzhdbi09gv8ioi 3y ago
About time, js cli apps were never a good idea.
- maccard 3y ago
  They exist because it's significantly easier to distribute js apps than it is to distribute a compiled app. npm install works on Linux, Mac and windows, regardless of what libc, Msys, crt, you have installed. It could be python, but pip is a usability nightmare
  - boredumb 3y ago
    Not particularly true especially in this case. You can get a rust binary and run it anywhere regardless of libc or having cargo installed on the users machine. A Javascript CLI requires nodejs and npm to be installed before running it.
    - rob74 3y ago
      Same goes for Go BTW. I even find it easier to install Go (haven't done it for Rust that often yet) and compile a binary (of a "pure" project that doesn't involve C libraries or other complications) than installing node/npm/nvm/whatever to get something up and running...
    - maccard 3y ago
      In this particular case, you wouldn't be installing oxlint unless you had npm installed already?
      - boredumb 3y ago

PoignardAzur 3y ago

There's also Deno: https://deno.com/ https://deno.com/

pzmarzly 3y ago

To clarify: I'm also not advocating for merging the codebases together, that would be mostly counterproductive (especially since Bun is in Zig, and Oxc and Biome in Rust). When I think why Rust was successful at establishing community-accepted standard tooling (clippy, rust-lsp), 2 things come to mind: - Project developers were always promoting each other's tools, pointing them out in docs or blog posts - Good tools were being pulled into rust-lang GH org (for visibility) and rustup CLI distribution (for ease of system-wide installation) Both of these things are not technical challenges, they are rather more "political" (require agreements between parties). In JS ecosystem, what would it take for Oxc to say on their website "we are not writing a formatter, please install Biome" and for Biome homepage to say "we are not writing a linter, please install Oxlint"?

thatxliner 3y ago
Except Biome can also function as a linter
conaclos 3y ago
Biome is the continuation of Rome Tools. It exists since several years and always featured a linter and a formatter. If I remember correctly, OXC was born out of its author's desire to learn Rust and his feeling that Rome Tools/Biome had made complex technological decisions (mainly the use of CST instead of an AST). Rome Tools/Biome chose a CST to bring first-class IDE support: you can format and lint malformed code as you are writing it. I hope more collaboration between Biome and OXC in the future. However, the inherent difference comes from technological choices.

conartist6 3y ago

[3] https://github.com/bablr-lang https://github.com/bablr-lang I'm its author and focus solely on the collaboration picture. I don't generate much press because I only build internal APIs for tooling and language authors, where the projects you've shared all opted to prioritize fulfilling specific real use cases over generalizing their core technology. Cruel as it is, I think all of them have planted the seeds of their own failure by failing to protect their organization's mission and day-to-day work from being jailed by a set of specific opinions about code style, which cannot possibly be "right" or "wrong" but must instead by argued about forever. I see the core challenge as shifting all editors and tools to share a common DOM representation and be interoperable in a per-node way, where the current solution is to use siloed and reimplemented tools which interoperate mostly in a per-file way, with each tool parsing the text, doing some work, then emitting text for some other tool to parse...

conartist6 3y ago
For example: "The Oxc AST differs slightly from the estree AST by removing ambiguous nodes and introducing distinct types. For example, instead of using a generic estree Identifier, the Oxc AST provides specific types such as BindingIdentifier, IdentifierReference, and IdentifierName." Already this is getting into matters of style! It is one style, yes, but Javascript's shorthand syntax `({ foo })` already breaks the mental model: the identifier `foo` is technically doing the work of both an IdentifierName and an IdentifierReference. OXC chooses IdentifierReference so any system built on top of it would need to contain additional logic in order to be able to identify all sites in code that are used as identifier names.