Bun is bundling everything and making it really fast, while also striving to maintain as much compatibility as possible with Node. It doesn't throw away the existing ecosystem.
Deno took on too much of an adversarial perspective towards the Node ecosystem and now they're working towards re-adding support.
So in terms of a successor, I'd say the only option is Bun because it's still trying to maintain compatibility with Node while innovating with new features.
For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all.
The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
I say now, anyway!
Why Bun uses WebKit/JSC was described here:
> One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that.
via https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-ar...
1. Missing `node:http2`
2. Missing `node:test`, so it's more difficult to execute the same test files within Bun as we do via Node. I wrote a custom Bun loader to mock parts of `node:test`.
3. Vite and ESLint do not work.
4. Still occasionally segfaults, and it's difficult to find out why/where.
5. Surprisingly, some code runs slower in Bun than in Node. For example, generating JWE with symmetric encryption. But this might be WebCrypto vs OpenSSL.
6. Subtle differences between WebKit and V8 (e.g., how they handle dates).I wasted a day trying to get vite to work when they first announced it. Really excited about not needing >1gb of ram to compile a react project... Boggles my mind that react bundling uses more RAM than compiling linux.
It is still unable compile http://chatcraft.org due to some problem with wasm plugin.
They also said that bunx --bun option was a pre-1.0 workaround, and didn't keep that promise.
Performance-wise their claims are suspect, safari js engine was always better at startup and memory use at the expense of a relatively weak JIT. They paired that up with a ton of stuff reimplemented in native code to make their cli and hello world workflows fast. This means people will be in for a perf surprise when they start bottlenecking in JS hotpaths.
In my benchmarks, our actual runtime performance of long-running JS code is ~25% faster under Bun than under Node. However, sometimes Bun is ~25% slower - notably with tasks that require binary processing (e.g, fflate, sharp) or encryption (e.g., jose). We're committed to JS and will be constrained by its performance for a long time, so a "free" 10-30% speed up at runtime is worth the effort, but it's not a 10x slam dunk like the benchmarks on Bun's homepage imply.
I did raise issues with repros for it only wasn't able to try to fix the issues myself. Building Bun is not working for me
I have never used Node and am creating a new project from scratch, so I don't know how worried to be about your commentary.
These days, if you're authoring from scratch, just write idiomatic TS in ESM, and you'll be fine. Even if targeting only Node, prefer to use Web standards (e.g., fetch, Request/Response, WebCrypto, Web Streams, URL, AbortController) as Node is migrating in that direction, and standard-compliant code will give you optionality in runtimes (Bun/Node/Workers).
I want to invest my time wisely and learn portable techniques, but I realize the scope of my ignorance may exceed what you can address in a comment forum!
Choose the tech stack that allows you to rapidly experiment in building something other people will give you money to use. That means choosing DX and iteration speed over runtime speed. That means using whatever gives you the most joy, so you're incentivized to build more often. That means something high-level so you don't waste time re-building components your customers don't care about, so you spend fewer hours on invisible, undifferentiated, but complex and time-consuming stuff.
If you're most effective with JS, Node is fine. Bun is fine. Deno is fine (for greenfield). One is super stable, battle-tested, and has 10x more contributors and 100x more libraries than the other two (most of them are trash). This maturity gap may not matter at all or may break your startup if you must re-implement something complex or continuously spend hours understanding and battling your runtime with minimal information on the web from others who encountered the same problem before. The same goes for your prod infrastructure, mobile app architecture, business ops, infosec, etc. Choose boring technology https://boringtechnology.club
I learned that problems that seem simple and solved apparently often aren't, regardless of how many blog posts and HN posts there are about the framework of the week. I needed to define an API, so I did so using OpenAPI. While the idea and standard seems mostly sound, the tooling (from editing to code generation) is absolute trash. I wasted soooo much time trying to make it work. Should I ever use it again, I'm writing my own tools. But right now I do just need to get stuff done.
While Node's performance story keeps improving release over release [1].
But, the command `bun install` supports NPM and custom registries, as well as Git and .tgz URLs.
Bun aims to be a better replacement to Node. There's less to consider so it's just a matter of if it's compatible enough and faster / better to warrant the switch. A lot easier to swallow.
I know very little about JS and TS and "modules," but from a newcomer that's how it all looks. I'm happy to have any further insight!
It seems Bun’s major selling point is performance. I can’t say I’ve really run into massive performance concerns with Node. It isn’t earth shatteringly fast but I’m way more likely to run into IO constraints than Node speed issues.
Deno’s major selling point was that it was Node Done Right in many ways: better packaging, ES6 all the way, etc. (a pitch I was sold on!) but it seems they gave up trying to create a new ecosystem and instead are adding Node compatibility.
Alongside all of this I'm encouraged by a number of recent Node improvements like having its own test runner and built in .env support. So I’m struggling to see good reason to use either Bun or Deno. Even if I were to switch I'd need to make sure I have a concrete path back to Node should the new generation tool become unviable.
This is extremely compelling for frontend DX.
The bundler stuff is certainly more compelling though the page doesn't specify what makes it better than rebuild except that it comes built-in... but that's where, for me, VC concerns raise their head. If I go all in on Bun bundler, what happens if the company switches their priority towards monetization and neglects the bundler? I'm going to have to unroll all the configuration work I will have done and go back to an external bundling library. And it's still not entirely clear what I gain!
Not sure how they plan on monetizing.
All valid ideas. But the involvement of VCs makes me wonder what kind of scale they're going to be expected to achieve and what will happen if they don't.
Feels like an acquisition by Cloudflare/Vercel is a more likely exit scenario.. But then if we get an HHVM repeat and most of the benefits are just introduced into Node proper what's the real value to the aquirer? Aqui-hire? Deno has raised at least $25m though, and bun $7m..
I guess most startups fail so maybe there is just no answer.
HipHop Virtual Machine was created over a decade ago to address serious performance issues with PHP. This spurred(lit a fire?) serious efforts to address the issues in PHP proper. Over a rather short period of time PHP became performant enough that HHVM was sunsetted.
I think the history here would call into question the viability of Bun as a monetary investment. It may end up a net good for the ecosystem , but if the major benefits can just be incorporated back into Node proper what are the ROI prospects?
I thought you're original comment was saying something to the effect of "VCs funded HHVM, and this feels similar."
I'd only heard of HHVM in the context of Facebook, so I was surprised to read that (but I know Phabricator was another infrastructure company spun out of FB, so it seemed possible).
Edit: sounds like this is changing. Thanks for the correction!
Any seasoned users with time spent on both?