Deno vs. Bun vs. Node.js: A feature comparison(dev.hexagon.56k.guru) |
Deno vs. Bun vs. Node.js: A feature comparison(dev.hexagon.56k.guru) |
"Built in" means nothing because the value prop of node compared to the other two is the ecosystem and maturity. Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? "Secure by default" in particular means nothing by itself here either.
Bun specifically promises better compatibility with existing npm modules then Deno so the comparison here is much different than the chart would lead you to believe.
In general I would expect a linting tool or any other component that is a first class feature of the app would be less likely to be released with bugs and breaking changes than a third party one.
With that in mind it’s probably impossible to build a linter that’s going to be able to serve these needs that’s also built-in and on the same release cadence as the runtime itself.
My point was that the feature checklist here is so surface level it's useless as a practical comparison.
I'm all ears! Will revise it later today
Not sure about you, but I really do hate Babel, Prettify, tsc, uglify and all that. I think it's awesome that they are integrated in Deno and Bun, and starting to get integrated into Node.
We all know that Node has a massive ecosystem, job opportunities and all that, do I really need to list that as features? I don't think any company would read this and think "Woah, let's ditch node!"
Should I list "better compatibility with existing Node modules" as a feature for Bun?
The promise of Bun seems pretty good, but I think their marketing material is further along than their core projects atm.
There was discussion about this the other day. It's marketed as a "drop-in" replacement but from perusing HN and elsewhere I see people having issues with real projects. It looks like a promising project, which I hope succeeds, but there also seems to be an unfortunate amount of marketing that, as you note, is being uncritically repeated.
I would consider it only for backend nodejs at the moment.
I think people are surprised that the performance claims don’t completely disappear with real world scenarios. It seems like a lot of eventually successful platforms began in the same way: the claims about improvements are real, and there are still a lot of rough edges.
Both Bun and Deno are made by companies with heavy VC investment. Node is not. Don’t want to state the obvious but those VCs want to see a return on their investment and that makes me very hesitant to invest in Bun or Deno, especially at this early stage.
Don’t know if it’s coincidence or if the competition has lit a fire under the Node project but it’s recently been adding some great stuff like a built in test runner and watch mode. I’m optimistic.
Its all about how it integrates and how it avoids vendor lock in.
Even if Bun didn't have a better performance story, I would evaluate switching to it to reduce project complexity.
Great tools have knock on effects. Good dependency managers improve the ecosystem. Fast language servers can enable interactive dev style. And so on…
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.
Both Node and Deno, using V8, do not support those so some (functional) algos are harder to express there.
This is a helpful overview, though I would also like to see a deep dive on some categories, like security (Deno permissions vs Bun trustedDependencies).
* Or maybe Deno has one too: https://news.ycombinator.com/item?id=37475462
Has anybody replaced everything with Bun in their 100 dependency project with a loose scaffolding of a deprecated node version due to some crucial dependency
This is the kind of thing I want to see even before using bun in a greenfield project
It is crazy that every web framework these days is trying to re-solve bundling for browsers
Would be really nice if we could send UDP messages directly from the browser, but it is understandable from security perspective.
so far because I can still deploy out the box in other places its flying under my radar
and its just convenient that vercel is easy to be a place of simple free deployment, for now
when they pull a Heroku I’m gone.
Rust/Cargo is the one I was most impressed by. But I haven't done any significant work in Rust.
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.
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.
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.