Deno vs. Bun vs. Node.js: A feature comparison | Hacker News Reader

Deno vs. Bun vs. Node.js: A feature comparison

dev.hexagon.56k.guru

90 pointsbirkskyum55 comments

I wasn't expecting a deep and thorough comparison just from the headline... but the feature list and comparison text here is worse than I thought it would be, bordering on useless.

"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.

> Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes?

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.

Sure, maybe. How would you know without doing some research into a specific project?

My point was that the feature checklist here is so surface level it's useless as a practical comparison.

Maybe?

In this day and age the “linting” tool does a lot more than just respond yes or no. It usually has a rules engine, templates, config file support and enforces a lot more things than just syntactical correctness.

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.

> worse than I thought it would be, bordering on useless.

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?

I think the problem with what you have now is that the feature comparison values "built in" above any other qualities. Obviously would require a much bigger article but I think the only way this is useful is if there is a comparison of tools in each runtime and "built in" is simply a pro in that comparison.

How about something like "<green check> (Built in)", "<green check>(Native Ecosystem)", "<yellow check> (Third party), "<red cross>" as a fix which avoids loads of text?

In my opinion that would be much more helpful than what was there before, it still gives preference to built in tools above all other criteria but you at least avoid the false impression that tools provided by the ecosystem don't exist.

Done!

"Secure by default" means something. It means Deno is a more appropriate choice for running untrusted code compared to node.

Bun is getting a lot of hype due to all the press, but almost everyone is just echoing Bun's docs and marketing material and lack direct experience using it. I haven't done a deep dive into Bun yet, but I have tried porting a legacy project to it. Hit a lot of issues after a few hours of hacking around. It wouldn't correctly install node modules because of opt-in dependency lifecycles (and maybe other issues?) and then I couldn't use it to execute the existing webpack build without encountering opaque runtime errors.

The promise of Bun seems pretty good, but I think their marketing material is further along than their core projects atm.

Wasn’t version 1.0.0 released three days ago?

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.

> 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.

It seems like it has potential but I tried using it with a Shopify app I am building and for some reason it wasn't automatically creating the cloudflare tunnel in dev mode. Also, there's no verbose flag to show more detailed log message.

I think running a bundler on top of bun defeats half of the purpose of the tool, unfortunately bun's own bundler is still very lackluster and definitely not good enough to use. On top of that most of the popular frontend frameworks (Vite, NextJS, etc) are doing their own bundling so I wouldn't use bun with those tools either.

I would consider it only for backend nodejs at the moment.

There’s an important column missing in the table: ownership.

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.

That is true. Both deno and bun runtimes are released under MIT license, and might potentially outlive the companies behind them.

So this is a good thing with regards to your parent comment? I.e., should we feel safe using Bun despite heavy VC investment?

It depends on the project how conservative you have to be, and what to emphasize. Generally, this company is very fast moving, so waiting some months could make it significantly easier to gauge if it's a good fit.

There are a relative handful of people willing and able to work on these projects. Lots of OSS software just gets abandoned when their corporate sponsors stop developing them; like Chakra Core and a bunch of Mozilla projects.

My positive experience with NextJS by VC backed Vercel ($2.5bn valuation) makes me not skeptical of a package by mere nature of it being maintained and marketed by a for profit company with heavy VC investment.

Its all about how it integrates and how it avoids vendor lock in.

I feel differently about next.js after their latest shenanigans. Their end goal clearly seems to be vendor lock-in to the Vercel/next.js platform, whichever way it ends up happening. The current attempt looks to be to tweak and assert control over the React library, to make it Vercelified.

you mean like with the app folder?

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.

Fixed!

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.

Does not Deno aim for exactly the same?

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.

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.

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.

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.

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.

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…

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

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.

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

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

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

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

Deno does have a built-in package manager[1], the fact that it's not home-grown shouldn't be held against it.

[1]: https://deno.land/manual@v1.36.4/basics/import_maps

One under-advertised unique feature of Bun is that it supports proper tail calls, thanks to the JavascriptCore runtime.

Both Node and Deno, using V8, do not support those so some (functional) algos are harder to express there.

It was pretty clear what Bun’s advantages vs Node are, but less so vs Deno. This helps clarify it. It’s mainly that Bun has a built-in package manager* and minifier and Deno doesn’t. And Deno has a few extras Bun doesn’t. I imagine those will equalize somewhat with future releases.

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

Any real benchmarks with version 1.0?

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

Did this recently, on a largish project based on express and typeorm. The only issue we had was with a native image manipulation library in combination with alpine linux image which was an easy fix. Rest worked flawlessly. Performance wasn't an issue for us, Dev experience was really bad on Node and the amount of hacks required to get esm/commonjs working in tandem was insane. Bun got rid of a lot of those hacks and we are slowly cleaning up the codebase.

What about a built-in standard library? That seems somewhat important.

So where does all this backend activity leave frontend tooling? It seems the divide only grows despite the upstream attempts by the ES committee to bridge the gap.

It leaves frontend tooling in a great place. All these features like built-in test runners, typescript/jsx support, faster iteration loop are quite convenient. There is still work to do for both runtimes in getting a high level of support for all the front-end frameworks, but there is good progress.

Adding the bundler to the runtime is the way to go in my opinion, the code you write in your scripts/server should run exactly the same as in the browser and not require separate configuration (besides bundling-specific things like how to split your modules for lazy loading).

It is crazy that every web framework these days is trying to re-solve bundling for browsers

Can one use bun in combination with something like aspnet core to replace vite, for example? Or am I fundamentally misunderstanding what bun is?

For me, the key thing that is missing is dgram (UDP) support. Makes bun unusable for a lot of IoT scenarios.

Why would you want to use JavaScript in IoT scenarios?

Well, Node-RED for starters. Plus homebridge, and plenty of UPNP and protocol-specific solutions that, for some reason, are coded in JavaScript.

I do it at my company, to talk to microcontrollers. We have a few CLI tools we use for testing that run on NodeJS. Our web-wrapped maintenance desktop application also sends UDP packages directly to microcontrollers but there we do it a bit differently. We have a proxy that forwards websocket messages as UDP packets running in the native code of our desktop application.

Would be really nice if we could send UDP messages directly from the browser, but it is understandable from security perspective.

Isn't Deno under the strong commercial grip of a couple of corporate companies, including the one that develops it?

I think deno (made by Deno Company) and bun (made by Oven) are in quite similar situations here, both controlled by companies eyeing deployment services of their respective runtimes as the main source of revenue. Node is in the OpenJS Foundation, so it's in a different situation.

Reply on news.ycombinator.com