[rmonvfer]

I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node? Sure I understand that not every project is evergreen but isn’t Bun a much runtime in general? It supports TS execution from day 1, has much faster dependency resolution, better ergonomics… and I could keep going.

I know I’m just a single data point but I’ve had a lot of success migrating old node projects to bun (in fact I haven’t used node itself since Bun was made public)

Again, I might be saying something terribly stupid because JS/TS isn’t really my turf so please let me know if I’m missing something.

[port11]

I've mainly worked with Node for now 8 years, and recently switched to Deno. Even that switch was hard to do; not because things don't work, but you don't know when they won't.

Node has its share of flaws, but it's the de facto baseline against which things are tested and developed. I'm somewhat more comfortable working with The Main Thing.

The JavaScript ecosystem is nightmarish enough that many developers don't want to switch to the Next Cool Thing. I think many of us have had enough fatigue caused by new build tools, new bundlers, new runtimes, etc.

As of right now, Bun is not compelling enough for the potential headaches down the line.

(Maybe there won't be any, but I've spent weeks dealing with incompatibilities caused by a single TS minor update (which should've been breaking). Days chasing after dependency problems, after missing docs, etc.)

[rglover]

> why not use Bun and forget about node?

Because Node is controlled by and maintained via the OpenJS Foundation. Bun is a venture-backed startup. That would be fine, but multiple, direct requests from me to the founder (Jared) about what the business model is (what I personally need to say "yes" or "no") have gone without response every time.

That led me to the assumption that Bun may very well be technically superior (or at least on the track to being so), but I can't bet anything significant or long-term on it. I need to know that this isn't just an exit vehicle for the founder (masquerading as a desire to fix JS server runtimes). Silence to a simple (dare I say, obvious) question doesn't bode well.

[ChocolateGod]

I tried to replace Node with Bun, but had the following compatibility problems.

localAddress on TCP connections ignored, last time I tried it its no-op

Incompatibility with Node module APIs (https://github.com/spamscanner/spamscanner wouldn't work)

EventEmitter race problems (partially worked around with https://www.npmjs.com/package/eventemitter2)

Svelte vites dev server sometimes forever freeze until I wiped node_modules and reinstalled it.

[notsylver]

I have tried fully switching to bun repeatedly since it came out and every time I got 90% of the way there only to hit a problem that couldn't be worked around. Last I tried I was still stuck on some libraries requiring napi functions that weren't implemented in bun yet, as well an issue I forget but it was vaguely something like `opendir` silently ignoring the `recursive` option causing a huge headache.

I'm waiting patiently for bun to catch up because I would love to switch but I don't think its ready for production use in larger projects yet. Even when things work, a lot of the bun-specific functionality sounds nice at first but feels like an afterthought in practice, and the documentation is far from the quality of node.js

[prmph]

I agree. I've tried the Node TS and test runner features, and they are still (not yet) as good as Bun's. So for now sticking with Bun for those.

Really, in the Node ecosystem you eventually learn not to put all your eggs in one basket. Different things excel in different aspects. Here is my preferred setup for now:

Bun.js: As a Node runtime, and for TS execution and test running. I tried lots: TSX, TS-Node, Node itself

NPM For executing tooling scripts

PNPM For installing dependencies. It's simply better than the rest (npm, yarn, bun) for several reasons

Biome.js For linting (superior to every other tool I tried)

[hungryhobbit]

The bun test runner is definitely a lot better for testing than Node's.

But really, any test runner is beter than Node's: that thing is awful. It's like they looked at all the test runners in existence, and instead of copying what they all did, decided "let's make things harder for no apparent reason."

[motorest]

> I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node?

Why would you switch from runtime A to runtime B? I mean, you presented no reason at all, let alone a compelling one, to pick either one. So what leads you to believe it is a reasonable idea to waste time switching runtimes?

[madeofpalk]

> why not use Bun

I dislike being on the bleeding edge for things. NodeJS is the most supported in the JS ecosystem. I find it much better to just be on the "default" option for things. You know, choose boring technology.

[0x457]

> You know, choose boring technology.

Is it a boring technology? I remember trying Node.js when it just came out, and I don't think all that much improved. Whole node.js always felt one step forward, two steps back. A lot of early design decisions still hurt it.

I would call it stagnated before I call it boring.

[crabmusket]

If you are choosing from "all backend technologies", Node may or may not count as boring. It's certainly not as boring as Java.

If, for whatever reason, you need to run JS outside the browser, then Node seems the most boring of all the possible options. Certainly "rewriting all our JS code in Java" sounds a lot less boring.

[0x457]

Oh yeah, in that case it's for sure the most boring one.

[Normal_gaussian]

For me - it doesn't support secure and reliable dependency vendoring.

The best way to do this atm. is using (and configuring) yarn for zero-installs.

This keeps dependencies inside the codebase so that: * Issues can be easily traced to the code that actually ran - development and deployment are the same. * Deployment doesn't depend on package repositories. * Deployment is secure from many kinds of attacks. * It is possible to transparently patch packages. * Development is only internet dependent when adding a new package. * and the best ease-of-use - no reinstall when changing branches.

[theThree]

I'm using Bun, but I avoid using any Bun.* function, because I don't want to bind my typescript project to a runtime.

[silverwind]

Node is much more stable than bun. bun has numerous crash bugs, something that is unheard of with Node.

[hungryhobbit]

Bun is still a toddler: it's not ready for primetime.

Simple example: you know how at the command line you can type "npm run", and then type a character or two, hit tab, and the appropriate script from your `package.json` will autocomplete? And if you keep going (eg. "npm run knex") you can do the same thing to autocomplete arguments?

Bun still hasn't figured out how to do that (https://github.com/oven-sh/bun/issues/6037), even though they can all but copy NPM's (already written) completions. I really liked using bun when I played around with it (and it ran my codebase perfectly, without issue) ... but if they can't handle something as simple as Bash completions, they're clearly not ready for the big leagues.

[0x457]

Your indicator of technology maturity is "is there an autocomplete script for my shell" ? I have autocomplete working on any CLI app I make before it's even functional.

[hungryhobbit]

Exactly why it's embarrassing that Bun can't handle something so basic.

[0x457]

Sure, but IMO it's a weird metric to measure.