[ozten]

Bun's #1 killer feature is that web application tooling has become a nightmare that everyone dreads dealing with. Bun promises one tool designed for DX to solve bundling, testing, runtime, and more.

Even if Bun didn't have a better performance story, I would evaluate switching to it to reduce project complexity.

[klabb3]

I think that in general, tooling is underrated. In many ways, tooling is more important than the language itself (although some language features are intertwined with the tooling story). And I don’t mean more features, but rather consistency, reproducibility, simplicity, etc.

Great tools have knock on effects. Good dependency managers improve the ecosystem. Fast language servers can enable interactive dev style. And so on…

[hu3]

Agreed. Go is prime example of a rather (intentionally) unsexy language that sports great tooling.

[DanielHB]

I am not an expert in go, but I find its tooling not good at all, especially package/dependency management. But at least there is _less_ tooling required than most nodejs projects and _less_ tooling fragmentation in general.

Rust/Cargo is the one I was most impressed by. But I haven't done any significant work in Rust.

[dilawar]

+1. Before I could understand benefits of Rist, I was sold on cargo.

[zacmps]

I think rustdoc, rust-analyzer, and crater all deserve shout-outs as well.

[andyferris]

Does not Deno aim for exactly the same?

[ozten]

Good point. Bun promises compatibility with existing mainstream web development technologies (CommonJS, ES Modules, NodeJs APIs, Typescript, etc).

Deno promised "Node", but done a second time the right way (Typescript, new APIs, new package manager, etc). Which is not an entirely new language / platform, but different enough that you have to buy into the Deno vision.

[jauntywundrkind]

Deno in my view was promising web.

They actively fought against being Node at all for a long time, & differentiated themselves in being much much less, no package.json at all. Only recently has Deno gotten deep Node intercompatibility, after years of trying to leave that shit behind & finally giving in to the needs to be part of the vast npm externality.

The general principle has & still is evident. It's not totally picture perfect rosy - there's lots of pieces missing - but Deno's http serving for example uses standard w3c Request Response objects used by Fetch & Service Worker. https://deno.land/api@v1.36.4?s=Deno.serveHttp

But more so, things like typescript & formatting come out of the box & are crazy fast/just work.

[zarzavat]

I just don’t understand why I would want to use Deno. I totally get the idea of wanting a modern Node, and I can appreciate Deno as a form of art. But does it help me do my job better than with Node? The browser API compat doesn’t move me at all, I can have that in Node as well… same with Typescript, it works just fine in Node, in fact I like having it separate because I can configure my build exactly how I want.

[jauntywundrkind]

I've spent way too long fighting node.js having bitterly sad compromises in esm support. I've spent way too long hunting through tsconfig options looking for some option that maybe might help.

These problems keep recurring. Every time I start a small library, yes, I know I'll make it through, eventually. But I feel lessened by the battle. Compromises are made.

I personally feel little enjoyment for configuring build chains. A good fraction for the packages I download have people that made cute interesting personal decisions about how to package stuff - since there is no guidance & no standard - that clashes & conflicts with everything else. Or is distributed as es2015 cjs. Other people's ability to choose, their ability to like configuring their build actively impedes the general flow.

Most people dont get the web platform compat. But unjs, cloudflare workers, and dozens of others are just amazing lovely platforms that work so well, and which are often fairly cross portable with little lift. It's fine that you are happy in your niche, but having actual well adopted interoperable protocols has let some really interesting pick & choose futures start to emerge, and it's where the early adopters are. It's where the good stuff is formenting. You don't have to be there now, you can stay in your zone, but is is growing, and it's because of wintercg interoperability efforts all centered around growing web platform ideas outward.

[zarzavat]

That’s fair enough but you can do most of these things in Node too, it doesn’t require a new runtime. You can use browser APIs by installing a wrapper, you can use ES modules, you can (I believe) use workers although I haven’t tried that yet.

The packaging situation is indeed messed up but that’s because TC39 decided to invent a maximally incompatible new module format. But you can not install CJS packages in Node just as well as you can not install them in Deno.

I don’t find configuring build systems enjoyable, but the benefit is that your dev environment is not tightly coupled. If your runtime is also your build system then there’s one tool doing two jobs. Some people might like this. I personally think that this kind of coupling causes more inconvenience over the long-term even if there’s less inconvenience up front.

[no_wizard]

it can't build stylesheets or run a headless browser yet, so its not entirely a one stop shop

[dzogchen]

I would argue that random segfaults are not particularly good DX.