Hacker News Reader

Comment by alberth | Hacker News Reader

Dumb question: which appears most promising? Deno, Just-JS or Bun?

(Genuine question. Not trolling)

From the little I've read about just-js, I'm not sure it's even trying to be a competitor with the others for their main use-cases

I think Deno has the strongest overall vision, and it's a vision I really want to see become the new default

Bun is compelling with its blistering pace and its ruthless dedication to performance, compatibility, and Just Works user experience. However, it's still very new and missing a lot of key features, and subjectively it just feels too "chaotic" for my tastes. They're designing it as they go, as fast as they can, but it feels like a wild ride. I'm not sure the creator even knows exactly where it'll end up, and in general it seems to prioritize "does everything you'd like it to right now" over "lay a new, better foundation for how the JS ecosystem works, unburdened by the historical baggage of Node"

Two very different mindsets; it'll be really interesting to see which one wins. Personally I'm rooting for Deno, but I think each of them is pushing the other one to be better.

> unburdened by the historical baggage of Node

Is this even possible anymore?

Deno made a valiant attempt, but with every release, the best received update seems to be the node/npm compatibility.

What's interesting though is that the compatibility effort seems to be on all sides. Deno has acted somewhat like a forcing function - I think a lot of Node folk want to move away from CommonJS in general (even staying within the NPM ecosystem) & having multiple targets for modules you write has given that effort some good pushes.

A simple example of this in my mind is the node: prefix added to CommonJS functions in NodeJS. This has some perf/caching advantages, which may have been the main driver, but also introducing a protocol prefix to module strings happens to improve extensibility/flexibility/compat across the ecosystem - there are transpilers that change e.g. import to require() or vice-versa, so extra context in module strings is helpful there. Deno's npm: prefix has a similar effect (it would be cool if this made it into Node someday - having control over module locator strategy at import granularity seems interesting; it would certainly make a lot of bundler hacks currently in use for things like CSS/etc. simpler)

I see NPM compatibility as a temporary stopgap. They tried to make a hard break all at once, and then Bun made it clear that no, actually people still really want access to that existing ecosystem for now.

But new code written for Deno starts out on that better foundation without CommonJS, several different module-resolution algorithms, manual transpilation, competing linting and testing standards, etc etc. They just need to bridge the gap in the meantime, until Deno's own ecosystem gets more filled out. That's the dream anyway.

The pedigree of Deno does speak for at least something as well. Who better to address the flaws of a lasting project someone created than the creator themselves? Just from incentive alignment it’s a powerful motivator.

My on-the-sidelines take is:

Bun seems most promising to me, because it's chasing amazing performance _and_ widespread adoption.

Like Just-JS has amazing performance [1], but the author is "just" (a very amazing/talented) benchmark hacker and not necessarily trying/wanting to put in the effort to have "a node replacement" and/or extend his Techempower-specific optimizations into APIs/libraries that would affect the performance day-to-day business apps (which I don't blame him for).

Deno is kinda :shrug: b/c its original "great security" pitch doesn't really matter to anyone who runs in containers.

[1]: https://github.com/just-js/just.billywhizz.io/issues/3

As a quick note, while containers offer a degree of isolation, depending on your use case you might not want to put too many eggs into that basket (Linux privilege escalation bugs do happen). E.g. Firecracker VM is a relatively easy improvement to make of course, and on cloud env the container isolation might be Amazon’s/Microsoft’s problem. Just figured it would be good to mention not to see containers as a silver bullet, while they are better than not using containers on a shared host (and a useful tool in general :-)

Bun is the most excited I have ever been in the JavaScript ecosystem.

My guess is none of them will ever replace Node.js, but they will all help shift the momentum of Node.js to be faster, better support for Typescript, etc. Similar to how folks created io.js at one point and that eventually got merged back into Node.js.

Deno seems like to offer a better dev experience, and because it's created by Dahl it's the only one I take seriously as an alternative.

imo just-js and bun are too early to tell. They're in that stage where they're cool and people talk about them, but they haven't gotten to that stage where there's adoption and therefore real criticism. Basically bun/just-js are being judged on their potential, while Deno is starting to be judged on its reality.

I think they all serve different use cases. I'm not sure I could say one is more promising than another, because they're _all_ promising, and I don't see them as being in direct competition with each other.

Your question taught me that Just-JS and Bun exist. Thanks for asking.

I'd say deno, because they've already established a proper ecosystem since day one, has a working usage such as Deno Deploy[0] and Fresh[1], and already addresses some issues about distribution issue on Node, while bun still acts like a replacement for Node.

[0]:https://deno.com/deploy

[1]:https://fresh.deno.dev/

I have nothing bad to say about the other two but Deno is pretty great, I'm hoping it topples node.js at least, it seems poised to do so. Really lookin forward to playing with deno deploy too.

The author of Just-JS is working on Deno as well.

the three, after they merge into one :)

While I suspect you're joking.. this doesn't seem likely given that all 3 are written in different languages

Reply on news.ycombinator.com