If you deep dive into bun, it only has the gained performance for certain features and cant really even be compared to deno or node at the moment because it lacks so many other features that would better showcase its speed.

I had a huge jolt away from the Bun hype-euphoria when I noticed it won't run Express.

That level of incompatibility is the banner headline not some minor footnote, which is effectively how the bun team decided to communicate that little detail.

If they're going to do things all-over-again...again in the JS community couldn't they get it right this time and go with speed, stability, compatibility...

Instead of hype and cute mascots?

Here's a good summary that details your point on what Bun does well and where it lacks - https://levelup.gitconnected.com/is-bun-js-the-node-js-kille...

Hm, that claims SQLite is 'never' used for web backends; Bun says it's motivated for use 'at the edge' - first thing I thought of when I read that was Fly.io/Litestream: https://fly.io/blog/all-in-on-sqlite-litestream/

(No idea if there's any relationship between the projects, just makes me think that article's a bit dismissive.)

This was the impression I got as well, but that instability was preventing some of the benchmarking from happening.

The "npm:" import does not appear to have even started development, although it has been planned for a long time: https://github.com/denoland/deno/issues/13703

Core features for npm compatibility though (like implementing most of the npm api, including require(), and its special globals) has been making progress for a long time.

There is even a near complete project to support Node's native api (which bun also supports): https://github.com/denoland/deno/pull/13633

Relative to the the existing node compat efforts, the url import (and accompanying package download code) will be fairly small. The most difficult part is probably the extra stuff that node throws in the global namespace. How to handle that without having to pollute the global namespace for all programs (even those that do not import from node) is unclear.

Ideally these globals would be visible only from code in modules imported from npm. But the spec does not really allow for this unless the npm code is loaded in a different realm, but cross realm code causes a lot of headaches, which could only be avoided by having the realms share most globals and intrinsics (and sharing intrisics is not allowed by the spec).

There may be some other way to hack this into working, or perhaps programs with such imports that actually use NPM specific objects will need to be run with the "--compat" flag. It is really unclear at the moment.

> The "npm:" import does not appear to have even started development, although it has been planned for a long time: https://github.com/denoland/deno/issues/13703

The development is well under way, we expect to ship first iteration of this feature in the next release (v1.25) in the coming weeks.

Heh, I commented in that post from yesterday how Bun looked more promising longer term to me than Deno, even though it wasn't production ready yet: https://news.ycombinator.com/item?id=32460658

Like you said, don't know if Bun had an influence on the timing of this announcement, but great to see innovation in the JS server space. Kudos to both the Deno and Bun folks!

My guess is they were planning on announcing these things sometime in the next couple of months, but then Bun showed up on HN, so they moved up the blog post.

"We aren't optimizing for a handful of edge cases, but for overall real world performance" seemed indirectly a call out to Bun.

Deno's progress on NPM compatibility may have accelerated due to how BunJS was received, but yes I believe this idea has been baking for a while in the Deno world. It was always somewhat of a concern when Deno was launched, but the team was just more focused on delivering a solid core product before they started worrying about the ancillary tasks. After all, you can always use the various Deno-friendly CDNs to use a Deno-compatible package distributed over NPM.

BunJS does of course have a slightly different use case, packages or apps that still need to make use of Node APIs. I can see a future where we say "if you have an old Node app, you can run it on BunJS with a codemod and get an X% perf boost for free", as well as "if you are starting a new project, just go with Deno because there's less BS to think about".

I think it has more to do with the money they raised and communicating some path towards wider adoption.

Don't personally know anyone who is treating Bun as anything more than a curiosity.

Npm is the main thing I dislike about Node though. I hope compatibility is a feature meant for easing transitions, not something the general user base should be embracing.

I imagine yes, bun put pressure on to launch node package compatibility.

Any thoughts on speed reliability concerns comparing the two?

Their comments about the performance were definitely a consequence of Bun's release.

It's the drawback but also the problem.

NPM is a giant pain point, and I suggest that Deno and a lot of other people want to move on from it.

But the gravity is just too much.

Such gravitational force for sure, node_modules size is huge.

Sorry.

NPM is one of the major drawbacks of the whole JS ecosystem.

It's a package manager, package managers are almost always entirely optional.

Feel free to gather and build your dependency trees by hand, if you believe this to be worth it. Most packages have their sources and build instructions readily available on GitHub/Lab :)

NPM isn't just a package manager, if you don't exist on NPM you are nearly invisible.

Don't downplay it's importance and it's disadvantages that came along.

There are too many examples where changes to packages have had serious consequences.

Left pad and node-ipc to name the better known.

These problems exist with every package manager, and every ecosystem of reusable modules that can be downloaded from a 3rd-party location. The problems that `left-pad` caused are minuscule compared to the ones created by Log4J. It's just the trade-off you make when you download a package from the internet vs when you write the code by hand. NPM may have more instances these days because it happens to be the most popular, but CPAN had the same problems over 20 years ago. The next package ecosystem to come along will also inherit a vulnerability to supply chain attacks, being part of the supply chain.

I don't think NPM is the best way to create a package manager, in fact there are many choices they made that I think are rather stupid and led to many more problems than there needed to be (whoever decided that the default for `npm add` should be a caret dependency instead of a tilde should never be allowed to work in the industry again, IMHO). But I'm not going to blame them for a problem that definitely existed in the package management world before them and will continue to exist long after everyone forgets about NPM.

The default should be shrinkwrap, like `yarn`, with the ability to upgrade packages manually when you decide that it's a good time to upgrade packages. I don't like things changes at all without explicit interaction. Services like Snyk will let me know if there's a specific security concern with a package version I'm relying on.

Which is why I use `yarn`, I guess.

> Don't downplay it's importance and it's disadvantages that came along.

This is rather unfair.

Your previous comment referred to NPM in the broadest possible sense, so what else would you expect its audience to do but to interpret it in the same way?

It is primarily a package manager and so I assumed you didn't like it for how it functions in that capacity.

That is not to say that I disagree with you - it's their priorities and stubbornness on major issues that I myself take issue with, but I'm complaining too much already in general so I'll leave it at that.

On the types of customers I work with, none of them matter.

Until I get a customer requirement to use anything other than nodejs, then I will consider another look into them.