Bun 1.4 Rust rewrite is not looking good?

It's 1/2 baked in everything it tries to do.

You need a "separate" tool called npm to install packages. It's dead slow so they added corepack. Another extra tool. Then you use it to install yarn or pnpm. Another extra tool. It might still be slower than bun...

In the past you need to transpile typescript with other tools. It can only run js out of the box. The later fix was a wasm build, which means slower than it could be. Another 1/2 job.

Many more examples in many areas but anything Node tries to do itself feels 1/2 baked.

Bun and Deno are faster than Node because it is a 1/2 job at its core. It has v8. It has the tools. It could be done but no. It did nothing for years until Deno and Bun came on the scene to nudge it.

That's a fair criticism... they move slower but mostly because they were the first. They would have to build a new Server and Request/Response primitives from scratch, or deprecate what they already have, or somehow shoehorn the existing types into the new ones.

They do seem to have just merged in support for Web Workers though, which I've been following for a while: https://github.com/nodejs/node/issues/43583

So I don't think they're opposed to standardising, but it's trickier when you have some past cruft built up. Lets not forget that the fetch() standard was built for browsers, and is a bit of a stretch to make it work on servers at all. You have to diverge from the fetch spec to even make it make sense in a server environment (with things like Cookies handling off the top of my head).

Let me address each one in turn:

- esbuild - this is normally for TS compilation, which Node can run natively now by stripping types: https://nodejs.org/docs/latest/api/typescript.html#type-stri...

- jest/vitest: Node has a test runner: https://nodejs.org/docs/latest/api/test.html

- dotenv: Node can read .env files: https://nodejs.org/docs/latest/api/cli.html#--env-filefile

Performance, maybe you're right - but if you're doing any IO, I doubt the runtime is really the bottleneck.

In other words, it hasn't shipped.

The bun rewrite is looked to as proof that this sort of full-throttle vibecoding is the future of software development, at least for large porting projects like this one, and for many people on this site that is a high stakes question.

To prove that, a proper release is needed, and the Bun community needs to adopt it. There's a huge partisan eagerness to declare the Claude Code release or anecdotal experiences on the canary as victory, but the viability of 1.4 hasn't been demonstrated until it has been released and adopted by the bulk of the community.

There isn't actually any hurry on that. Nobody needs Bun 1.4 tomorrow. It's Jarred that keeps saying it'll be released tomorrow, while the code churns at an astonishing rate (see below). People with a skeptical outlook will inevitably suspect that he doesn't have confidence in the release and is struggling to acquire it.

Github insights for the last week:

> Excluding merges, 57 authors have pushed 349 commits to main and 6892 commits to all branches.

> On main, 2026 files have changed and there have been 189,502 additions and 133,836 deletions

For me the real test will be maintainability going forwards. Not a JS user.

I suppose it’s one thing to rewrite code and make tests pass. But a lot of my own CPU cycles when coding go to making the code understandable, modular, editable etc. IME Claude is not great on these.

Maybe it doesn’t matter? Maybe the spaghetti makes sense to Claude, and when you say “hey add this feature”, no problem?

But maybe it will turn into a worse ball of spaghetti, with no nicely curated tests, hacks on hacks on hacks and never ending loops of whackamole of “just change this one line and rerun tests”.

I can imagine both - let’s see.