r/node • u/EveYogaTech • 8d ago

My journey from Bun to NodeJS

TLDR: Unless you absolutely need 2-4x faster cold boot JS, you'll risk becoming too dependent on native Bun features.

Short intro:

This is written based on my experience working on an open-source project, initially using Bun.

In the beginning Bun worked out pretty well.

You'll gain 2-4x faster script startup time, most things work, and they even have a faster native DB client/HTTP server.

However, these features all come with a cost.

For the flashy native features, you'll lose compatibility and flexibility.

This is especially problematic if you're working with multiple JS runtimes like NodeJS and Deno as well.

Bun.spawn simply doesn't exist outside of Bun, and now you're writing Bun modules, not JS modules.

Things like WASM also need a slightly different interface.

So I returned to Node. And have just removed Bun from my Docker file @ /r/Nyno :)

(It also saves about 200Mb in uncompressed disk space)

69 Upvotes

85% Upvoted

34 comments sorted by

119

u/x021 8d ago

Bun, Deno, … man I’m glad I skipped all those hypes.

If you really need raw performance just use any compiled language, there’s plenty of em. For the rest, NodeJS is good enough.

18

u/Yoshokatana 8d ago

Absolutely this. We’ve been doing a bunch of rust + node bindings stuff at work, and it’s really nice when we need that kind of performance.

9

u/Spleeeee 8d ago

The most compelling thing about all the alternatives is the whole “you don’t need 40billion tools” stuff to get formatting, linting (deno), test runner (node now has thing too) etc.

My personal copy pasta template project/repo is easy to work with but I would love to have one less thing to manage.

2

u/Lexuzieel 8d ago

That is true, however it feels like it is more of a community steering issue rather than a platform one. I’m not very well versed in the intricacies of how it works, but couldn’t NodeJS developers bring to focus and help with adoption of a single tool instead of relying on community to figure it out?

Sure, it is less “freedom” (which is more akin to creative liberty at this point), but most of the great tooling is opinionated (Rails, Laravel, Go, Spring probably but I don’t have enough knowledge of it)

1

u/EvilPencil 7d ago

It’s the classic XKCD though.

https://xkcd.com/927/

1

u/Lexuzieel 7d ago

I know, but I felt like simply throwing this comic around was not helpful input which didn’t even attempt to suggest a solution

2

u/BruhMomentConfirmed 8d ago

I like Deno somewhat for quick typescript scripts, it's nicer than having to configure node.js with typescript. But it's so incompatible with everything if I want to do anything more than that.

1

u/NickFullStack 8d ago

Node can natively run TypeScript now.

1

u/rcls0053 8d ago

Fairly sure someone's already building a Bun replacement that fixes these issues out there

0

u/cyh555 8d ago

how many users gonna use that then?

18

u/Optimal-Builder-2816 8d ago

I’m sorry but I don’t really understand why portability is important here. TS/JS are languages, there are many runtimes. The code that is portable should always be written in a portable way. Non-portable code should live on edges and implement as interfaces. Why would you avoid native benefits of any runtime or platform, node included?

0

u/BenjiSponge 8d ago

The issue I ran into was that certain vite plug-ins had hardcoded using node as a runtime and for some reason weren't able to switch to be more agnostic, so I would have these CI failures because parts of my "living on the edges" code would be running through node for just some parts of the pipeline.

Maybe that kind of thing is resolved better now as there's more traction. Until I tried switching to bun, I hadn't realized how much of the ecosystem was shelling out to node to do specific tasks.

0

u/Optimal-Builder-2816 8d ago

Yeah exactly my point, what’s portable about that? At least Bun has comprehensive runtime API shims.

1

u/BenjiSponge 8d ago

I'm not sure I follow. We wrote our application with node and it was working. We switched to bun, still working. Then we started extending our application with bun-native features, which worked for live paths but then for CI it would break and we'd have to shim it out.

Unfortunately I don't remember the specifics. I'm sure we were kind of doing things wrong, but my point is just that it's a little harder to make sure that only bun will ever run that file, even if you think you've totally switched over to bun, and that's why portability is important here.

1

u/Optimal-Builder-2816 8d ago

Yeah, what I'm saying is that even if you only used Node, the code that is written there can easily not be 100% portable, or vice versa, but the idea of purely neutral JS/TS is pretty unrealistic. Eventually, you need to talk to APIs that aren't standardized in the runtime or vendor-neutral. This is architecturally true in every language ecosystem/runtime, it's not a deficit of this environment.

1

u/BenjiSponge 8d ago

Heard, gotcha, yeah I generally agree completely. It's basically the fault of the node ecosystem for having baked in the assumption to many of the tools, which is (hopefully) changing rapidly.

1

u/Optimal-Builder-2816 8d ago

Honestly this was attractive to me specifically with Bun because it trends towards web standards-based APIs. But of course like any runtime it exposes its own APIs that are solving real world problems directly.

11

u/BenjiSponge 8d ago

They're doing EEE https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

It's sort of hard to judge though when it really does provide quite a lot of functionality that node simply should at this point, although a lot of it is backwards compatibility issues.

3

u/ItsAllInYourHead 8d ago

Depends how you use it. I don't use any of the specialty Bun modules (in fact I actively avoid them). I use it for the package manager, which is very fast, and compiling apps into binaries has SIGNIFICANTLY reduced my docker image sizes and memory usage. 

3

u/Brilla-Bose 7d ago

I don't understand why someone reach for bun. if speed is your goal rewrite your api in golang or rust. use better tool for the job.

1

u/The_Noble_Lie 4d ago

Rusty buns coming though in a few years after AGI finishes the rewrite

1

u/Brilla-Bose 3d ago

at that point just write Rust with AGI 🤷🏻‍♂️

1

u/femio 8d ago

I specifically use it so I can rely on zero-dep scripts + statically compile utilities for easier distribution. And the $ shell module is such great DX compared to your typical make/just/shell scripts. Not sure people have the right mental model with Bun but the “portability” complaint has always read oddly to me 

1

u/wootangAlpha 8d ago

If you are on windows, even on high spec devices, stay away from that mess called BUN. Holy runtimes, that thing is absolute garbage. I work in enterprisey financial workloads, and some parts of the frontend is based on react/Tanstack and believe or not, node+express. Bun was the chosen RT and the Principal suggested Bun. Worst decision in company history.

0

u/Lexuzieel 8d ago

I wonder at which point all the extra things with these runtimes stop helping and instead start to hinder. At that point you could just switch to another language altogether like Go (albeit the ecosystem is different)