I’ve been a long time user of Bun since v0.2, being an early adopter is a great experience; not only does it bring out the joy in programming for me, but it has the added bonus of giving me enough experience to know when and why I’d use a given technology. It’s taken me this long to come to the same conclusion as everyone else, which is that Bun is great for hobby projects and things which you just want to get up and running in short amount of time without setting up Typescript, Jest, ESBuild, etc.

Now any enterprise backend wouldn’t touch Bun, because of its lack of stability. For a long time I was under the impression that stability just meant running, if the software ran smoothly that was stable. Which is why when Bun first dropped along with Elysia (which I still use it’s awesome) I built my first hobby project, which was a chat app/twitter clone. It felt great, Elysia’s ergonomics are amazing, the app was blazingly fast and I was using the most cutting edge technologies. What more could a beginner software developer ask for? Most of all it ran, which is why when everyone said it was “unstable” I thought to myself, “what are you talking about, it runs fine on my machine?”

It took me a while to understand that true stability isn’t just software running, but sustainability as well. No one wonders if Node.js will be around in 10 years, because it’s funded by the OpenJS foundation which is backed by multiple Fortune 500 companies. Bun at the time had no such backing or plan for funding. Project goals also play a huge factor, Node is focused on backwards compatibility and keeping things running with regular release cycles and long term support versions. Bun’s sole focus is on performance and features while remaining backwards compatible with Node. Node also has a clear release cycle with each version receiving long term support for two and a half years as of right now. Bun, as far as I know, has no such release cycle Not to mention some updates even after v1.0 would break my existing apps. None of these are things to consider when building a hobby project since it’s not mission critical, but when building for production it’s best to at least consider some of these before having your entire application depend on something. This goes for just about every package, language, runtime or anything you use in you project. This doesn’t mean you always need to avoid the latest and greatest projects, but before you build your entire production application around a library with one maintainer and 12 stars on Github and zero funding you’re probably setting yourself up for failure. This isn’t to say Bun is maintained by 1 guy with 12 Github stars, just that there’s more to consider than just code when building for production.

Anything is useless if you don’t know how to use it, which is why documentation exists. Now Bun has documentation and its definitely improved over time, but my experience with this has been not so great. It’s not horrible, the commands and libraries are there, but its just to vague for my feeble monkey brain to understand. For example, for a few weeks I got stuck on my drizzle client not connecting to my test container. The container was running, the ports were open everything looked great but I’d get a connection refused error every time I ran the test with my setup function. I followed the documentation below and it seemed everything should have worked.

For whatever reason in my setup file, the environment variable definition wasn’t overriding the existing environment variable. I couldn’t figure out why, there was no documentation on edge cases where this would not work. The workaround I used was just mocking the Drizzle client with the recently defined variable.

Compare this to Node.js which tells you about the same thing, but also lets you know what happens when an error is thrown. I defined the environment variables just as I did with Bun, only thing that changed was the beforeAll() hook to the globalSetup() function. It worked like a charm first try, no workarounds just a feature that worked as it’s supposed to.

Another problem I had was with moving my drizzle schema over to packages/db inside of my monorepo (I know, monorepos are the root of all evil.) It worked, but for whatever reason the types were all messed up and I got type errors when I used any sort of WHERE clause. So I had no idea if I actually had a type error or not until I ran the tests. The sql function also just didn’t work, it seemed to be a version mismatch, except I was using Bun’s version catalog feature which is supposed to use the same version of a given package throughout the project. Compare this to Node, where I installed the same packages and versions just as before, yet everything just worked.

For awhile, I put up with a lot of these weird quirks and workarounds because Bun made things like Typescript, hot reloading and builds really easy. Most things just worked, so I figure the workarounds were worth it, until it really started to hinder my development speed. Many hours even days were spent tracking down weird bugs which should have been working as I followed the documentation exactly. I ran into many other bugs and documentation issues, but I kinda forgot all of them which isn’t important as I’m not trying to bash Bun here or tell you how terrible it is. Bun is an amazing piece of software that pushed Node to even build its own test runner and add Typescript support. Projects like these are what drives everyone to be better. However, what I wanted and feel like most people who use Bun want is just Node with full Typescript support and faster installs; without having to worry about compatibility.

After scrolling through daily.dev for a while I found exactly that nub it’s not a new runtime set on dethroning Node. It’s simply a Rust toolkit which removes a lot of annoyances with Node that made me switch to Bun in the first place. Things like full Typescript support, automatic .env loading, polyfills, hot reloading and Node version management (replacing nodemon.) This is what really sealed the deal for me, nub removes all of the pain points of Node with none of the downsides really as it’s just Node with some extra tooling.

A lot of this article was probably already information most developers already knew which is that project stability doesn’t just come from the code itself, but also funding, project goals, maintainers and community support. Community is a big one as just about every problem you’ll run into in Node someone has already ran into and has a fix for it, the same can’t be said for Bun. This is another big reason as to why most projects stick to what’s tried and tested instead of what’s most popular at the time.

Another thing which I haven’t mentioned is Bun’s Rust rewrite, as far as I know this still hasn’t been released as an official version just a canary, but it still makes me iffy about the project to say the least. I have no problem with AI-assisted development I use AI all the time when I get stuck on something and can’t find anything on Stack Overflow, but AI-driven development to me is a deal breaker for most projects. Again, to the best of my knowledge is hasn’t been officially released, but its still makes me nervous about where the project is headed.

The switch to Node also has its downsides, while Bun might not be as fast as its cracked up to be it’s definitely faster than Node and that’s just a fact, so I do expect to take a performance hit. However, if performance is your main concern, you don’t use JavaScript, which is why I don’t care.

Using the latest and most popular technologies in production usually comes back to haunt you later. In my case this was no different, yet I’m still happy I went this route, Bun is awesome and not only does it show how awesome a JavaScript runtime can be it pushes Node to be better; because of that things like nub and Node test runner were born. Node doesn’t just work, it works for a long time with lots of community support, security updates and a team of engineers constantly working to make it as fast as it can be without breaking your app; because of this it might never be as fast as Bun, but you’ll never have to worry about it breaking your app. You can rest easy knowing your app should be stable for the next couple of years.