[giancarlostoro]

What's funnier to me is none of them seem to want to abandon npm which keeps getting exploited and hacked. NPM has been the source of just how many industry wide hacks? Three major ones, and a massive supply-chain industry wide campaign against npm. But yeah, bun is the real concern here.

I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.

[zoogeny]

Who do you mean when you say "none of them"?

At the least, my interpretation of deno lore is that they tried to ditch npm and found this limited their adoption so significantly that they had to patch it back in. That would provide sufficient warning to me that attempting to move away from npm was unwise.

[__s]

https://news.ycombinator.com/item?id=48238789

[giancarlostoro]

Yeah, seems we're going to keep hearing people whine about Bun, while still using npm. This begs the question, what would make for the best NPM alternative?

[tracker1]

There's already JSR, FWIW...

[Eufrat]

I really think the actual problem is not the vibe coded aspect, nor questions about supply chain security. It is the apparently reckless and rushed nature of the rewrite which eroded user trust. In the span of about 2 weeks the narrative went from being an experimental branch to be being deployed as a canary ready for public testing. All the while the Jarred from Bun was posting here, promising blog posts and more transparency about what was going on. All that I can find is a single AI generated post (https://bun.com/bun-unsafe-audit) after people raised concerns about the quantity of unsafe calls in the Rust rewrite.

This is ridiculous and the response is entirely expected, it’s not about the code anymore, it’s about people. If you claim that doesn't matter, then I think the user response tells you otherwise. It signaled that Bun was not being transparent while asking people to trust it as a core runtime system. Why would I trust a runtime that actively would just do major changes so callously? There’s a balance between all of this. You don’t need to be as methodical as Python is now with PEPs. I think Swift got similar crap, though, nowhere as bad when it rolled out major language changes out of the blue to support Apple’s own product needs a few years back. This was kept secret and released in one burst, bypassing the entire Language Evolution process they crafted for Swift. Apple’s actions are more understandable by the nature of the company wanting to keep some things under wraps, even though it did erode trust somewhat. Apple is now a 50+ year old Fortune 100 company and Apple engineers really just kinda demurred on the bad taste it left in the community’s mouth, but at the same time, what do you expect from a company with a long history of being rather tight-lipped on major product changes. Bun has not really built this reputation nor has their parent company, but they are asking for that here and I just don’t think they have the leverage to do it.

They could have done this more methodically, made sure that the community and industry were okay with it. Maybe they actually did this more thoughtfully behind the scenes and this entirely a marketing stunt, but their lack of transparency at this moment makes it difficult to give them the benefit of the doubt. Trust is currently in short supply, burning it up on stunts like this is stupid.

[buu700]

Sounds about right. I think the response is a bit of an overreaction at this point, but an understandable and easily preventable one. It would have saved a lot of grief to have been more transparent and set clearer expectations: rather than yolo the experimental code into main, put it in a "v2" branch, publish an expected release timeline with 2.0.0 projected for ~Q4 2026 - Q1 2027, and announce a transition of 1.x to maintenance mode with only security fixes. The technical execution and release planning may or may not be excellent, but the political execution so far feels like an unforced error.

[Eufrat]

The other frustration is that the folks at Bun seem to entirely not get the problem they are creating for themselves.

One of the responses to this announcement was Jarred asking: “What issue did you run into with the Rust rewrite? If there’s something specific I’ll fix” Dude, this is a comms problem, not a technical problem. Refusing to accept that makes the situation worse and I think it is completely believable if Bun eventually dies over this because it’s clear the folks running the show don’t understand part of the process of winning customers is to build a community where Bun is just considered the obvious choice. I remember awhile back they also forked Zig to do some “optimization” that was pointed out by Zig maintainers to be worthless. There’s a pattern developing here and it’s not a good one.

[coldtea]

>“What issue did you run into with the Rust rewrite? If there’s something specific I’ll fix”

Besides, he doesn't mean he'll fix. He means "I'll let our AI vibe code a fix". We'd rather talk to the AI directly at this point, what exact value he adds?

[fragmede]

9 days just wasn't enough burn in. In an alternate reality, rust-bun ran in parallel for a least a month, if not three or six, before being merged.

[Griffinsauce]

Bun has always been about velocity over quality.

Their whole point was "drop in node replacement" - instead of hitting that target they built an entire framework of tools, seemingly changing focus every month or two, and are now rewriting all that to a new language.

[coldtea]

When you have infinite LLM coding monkeys, you don't ever feel the practical need to stop. Only the common sensical need, and if you lack that, you just don't stop. You let the code monkeys pile up more output.

Points to a badly ever-shifting platform at the whims of vibes and people with more coding resources than strategic plans.

[pier25]

> none of them seem to want to abandon npm which keeps getting exploited and hacked

Do you know of a better alternative for JS/TS that has all the popular packages?

[rglover]

Not perfect, but I use Verdaccio to run my own npm server and for third party deps, I clone, eval, and then if it's clean, push a safe copy to my own server (not for everything, just the most sensitive, hardcore stuff but eyeballing building a tool to semi-automate it due to recent chaos). You can even clone from remote URLs (point to a tarball from package.json instead of a version) so I've considered just using a private bucket.

Tedious, but makes the "npm hacked again" posts mostly moot.

[yoav]

Hi. Electrobun creator here.

I am building a new JS runtime called cottontail.

It’s just a prototype now but the goal is to have a huge standard library powered by native zig such that you don’t need npm.

So you’re right that npm is a disaster and I’m working on solving.

[TiredOfLife]

Also Rubygems, Packagist, PyPi

[ghusto]

pip install pulls in what I've listed in my package list, plus their dependencies which are at most 2 levels deep. The dependency's dependencies are reviewable.

npm install pulls in my dependencies plus god knows what else at god knows how many levels. 500MB of dependencies? The dependency's dependecies are not reviewable.

I wish people would stop trying to compare NPM to PyPi and others. NPM is an unfixable disaster because of the entire mindset and ecosystem around JavaScript.

[coldtea]

Somebody posted today about getting 3-4 pip top-level deps, and they brought in around 400 packages. That's not exactly that different.

[baggy_trough]

What's the worst hack to affect users of rubygems?

[pwdisswordfishs]

DHH, of course.

[tankenmate]

From my perspective it is a synthesis of "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." and "but npm is the source of all the shiny shiny!".