It’s a newer, vc funded competitor to the open source battle tested dominant player. It has incentives to lock you in and ultimately is just not that different from node. There’s basically no strategic advantage to using bun, it doesn’t really enable anything you can’t do with node. I have not seen anyone serious choose it yet, but I’ve seen plenty of unserious people use it

I think that summarizes it well. It's not 10x better that makes the risky bet of going into vendor lock from a VC-backed company worth it. Same issue with Prisma and Next for me.

I really want to like Bun and Deno. I've tried using both several times and so far I've never made it more than a few thousand lines of code before hitting a deal breaker.

Last big issue I had with Bun was streams closing early:

https://github.com/oven-sh/bun/issues/16037

Last big issue I had with Deno was a memory leak:

https://github.com/denoland/deno/issues/24674

At this point I feel like the Node ecosystem will probably adopt the good parts of Bun/Deno before Bun/Deno really take off.

uh... looks like an AI user saw this comment and fixed your bun issue? Or maybe it just deleted code in a random manner idk.

https://github.com/oven-sh/bun/commit/b474e3a1f63972979845a6...

The bun team uses Discord to kick off the Claude bot, so someone probably saw the comment and told it to do it. that edit doesn't look particularly good though

I am also very curious what people think about this. To me, as a project, Node gives off a vibe of being mature, democratic and community driven, especially after successfully navigating then io.js fork drama etc a few years ago. Clearly neither bun nor deno are community driven democratic projects, since they are both VC funded.

I am Bun's biggest fan. I use it in every project I can, and I write all my one-off scripts with Bun/TS. That being said, I've run into a handful of issues that make me a little anxious to introduce it into production environments. For instance, I had an issue a bit ago where something simple like an Express webserver inside Docker would just hang, but switching bun for node worked fine. A year ago I had another issue where a Bun + Prisma webserver would slowly leak memory until it crashed. (It's been a year, I'm sure they fixed that one).

I actually think Bun is so good that it will still net save you time, even with these annoyances. The headaches it resolves around transpilation, modules, workspaces etc, are just amazing. But I can understand why it hasn't gotten closer to npm yet.

Take a look at their issue tracker, it's full of crashes because apparently this Zig language is highly unsafe. I'm staying on Node.

That's why out if I had to choose a Node competitor, out of Bun and Deno, I'd choose Deno.

Good thing libuv is written in a "safe" language.

npm is a minefield that thousands of people traverse every day. So you are unlikely to hit a mine.

bun is a bumpy road that sees very low traffic. So you are likely to hit some bumps.

Zig isn’t inherently highly unsafe. A bit less than Rust in some regards. But arguably more safe in a few others.

But the language haven’t even reached 1.0 yet. A lot of the strategies for doing safe Zig isn’t fully developed.

Yet, TigerBeetle is written in Zig and is an extremely robust piece of software.

I think the focus of Bun is probably more on feature parity in the short term.

There’s a `crash` label. 758 open issues.

Well node is C++ which isn’t exactly safe either. But it’s more tested.

Neither Bun nor Deno have any killer features.

Sure, they have some nice stuff that should also be added in Node, but nothing compelling enough to deal with ecosystem change and breakage.

I think part of the issue is that a lot of the changes have been fairly incremental, and therefore fairly easy to include back into NodeJS. Or they've been things that make getting started with Bun easier, but don't really add much long-term value. For example, someone else in the comments talked about the sqlite module and the http server, but now NodeJS also natively supports sqlite, and if I'm working in web dev and writing servers, I'd rather use an existing, battle-tested framework like Express or Fastify with a larger ecosystem.

It's a cool project, and I like that they're not using V8 and trying something different, but I think it's very difficult to sell a change on such incremental improvements.

This is a long term pattern in the JS ecosystem, same thing happened with Yarn.

It was better than npm with useful features, but then npm just added all of those features after a few years and now nobody uses it.

You can spend hours every few years migrating to the latest and greatest, or you can just stick with npm/node and you will get the same benefits eventually

I have been using pnpm as my daily driver for several years, and am still waiting for npm to add a symlink option. (Bun does support symlinks).

In the interim, I am very glad we haven't waited.

Also, we switched to Postgres early, when my friends were telling me that eventually MySQL will catch up. Which in many ways, they did, but I still appreciate that we moved.

I can think of other choices we made - we try to assess the options and choose the best tool for the job, even if it is young.

Sometimes it pays off in spades. Sometimes it causes double the work and five times the headache.

If Node becomes much better thanks to the existence of Bun, then I think Bun accomplished its goals. Same for C and Zig.

There's still a few compatibility sticking points... I'm far more familiar with Deno and have been using it a lot the past few years, it's pretty much my default shell scripting tool now.

That said, for many work projects, I need to access MS-SQL, which the way it does socket connections isn't supported by the Deno runtime, or some such. Which limits what I can do at work. I suspect there's a few similar sticking points with Bun for other modules/tools people use.

It's also very hard to break away from entropy. Node+npm had over a decade and a lot of effort to build that ecosystem that people aren't willing to just abandon wholesale.

I really like Deno for shell scripting because I can use a shebang, reference dependencies and the runtime just handles them. I don't have the "npm install" step I need to run separately, it doesn't pollute my ~/bin/ directory with a bunch of potentially conflicting node_modules/ either, they're used from a shared (configurable) location. I suspect bun works in a similar fashion.

That said, with work I have systems I need to work with that are already in place or otherwise chosen for me. You can't always just replace technology on a whim.

I tried to run my project with bun - it didn't work so I gave up. Also, there needs to be a compelling reason to switch to a different ecosystem.

To beat an incumbent you need to be 2x better. Right now it seems to be a 1.1x better (for any reasonably sized projects) work in progress with kinks you’d expect from a work in progress and questionable ecosystem buy-in. That may be okay for hobby projects or tiny green field projects, but I’m absolutely not gonna risk serious company projects with it.

> 1.1x better (for any reasonably sized projects)

2x in specific microbenchmarks doesn’t translate to big savings in practice. We don’t serve a static string with an application server in prod.

There are some rough edges to Bun (see sibling comments), so there's a apparent cost to switching, namely wasted developer time in dealing with Node incompatibility. Being able to install packages 7x faster doesn't matter much to me so I don't see an upside to making the switch.

Tried it last year - I spent a few hours fighting the built in sqlite driver and found it buggy (silent errors) and the docs were very lacking.

Bun is much newer than pnpm, looking at 1.0 releases pnpm has about a 6 year head start.

I write a lot of one off scripts for stuff in node/ts and I tried to use Bun pretty early on when it was gaining some hype. There were too many incompatibilities with the ecosystem though, and I haven't tried since.

Honestly, it doesn't really solve a big problem I have, and introduces all the problem with being "new" and less used.

> I wonder why that is?

LLMs default to npm

You sure it's not just because npm has been around for 15 years as the default package manager for node?