5 ms·

Not sure if Bun has had an influence on this, these features must have been in development for a long time, but the timing surely is impeccable. npm compatibil

Not sure if Bun has had an influence on this, these features must have been in development for a long time, but the timing surely is impeccable. npm compatibility is huge for Deno. It is basically the one major drawback to Deno, which gets hopefully fixed with this feature. It also looks like this compatibility layer is implemented transparently in the existing module management, which is a big bonus. Nobody wants to deal with node_modules anymore when working with Deno for an extended period, just love to see this.

Zachsa999 4y ago
I imagine yes, bun put pressure on to launch node package compatibility. Any thoughts on speed reliability concerns comparing the two?
12many 4y ago
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.
- treyhuffine 4y ago
  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-killer-ffeb0f89196a https://levelup.gitconnected.com/is-bun-js-the-node-js-kille...
  - OJFord 4y ago
    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/ 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.)
- gureddio 4y ago
  This was the impression I got as well, but that instability was preventing some of the benchmarking from happening.
- jasonm23 4y ago
  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?
mcdonje 4y ago
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.
hn_throwaway_99 4y ago
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 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!
croes 4y ago
NPM is one of the major drawbacks of the whole JS ecosystem.
- krono 4y ago
  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 :)
  - croes 4y ago
    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.
    - tomphoolery 4y ago
      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.
      - 4y ago
tomphoolery 4y ago
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".
hinkley 4y ago
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.
jsmith45 4y ago
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 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 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.
- bartlomieju 4y ago
  > 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 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.
Rapzid 4y ago
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.
jollybean 4y ago
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.
- AbraKdabra 4y ago
  Such gravitational force for sure, node_modules size is huge. Sorry.
WorldMaker 4y ago
"We aren't optimizing for a handful of edge cases, but for overall real world performance" seemed indirectly a call out to Bun.
AbraKdabra 4y ago
Their comments about the performance were definitely a consequence of Bun's release.
pjmlp 4y ago
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.

Zachsa999 4y ago

I imagine yes, bun put pressure on to launch node package compatibility. Any thoughts on speed reliability concerns comparing the two?

12many 4y ago

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.

treyhuffine 4y ago
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-killer-ffeb0f89196a https://levelup.gitconnected.com/is-bun-js-the-node-js-kille...
- OJFord 4y ago
  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/ 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.)
gureddio 4y ago
This was the impression I got as well, but that instability was preventing some of the benchmarking from happening.
jasonm23 4y ago
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?

mcdonje 4y ago

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.

hn_throwaway_99 4y ago

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 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!

croes 4y ago

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

krono 4y ago
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 :)
- croes 4y ago
  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.
  - tomphoolery 4y ago
    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.
    - 4y ago

tomphoolery 4y ago

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".

hinkley 4y ago

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.

jsmith45 4y ago

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 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 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.

bartlomieju 4y ago
> 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 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.

Rapzid 4y ago

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.

jollybean 4y ago

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.

AbraKdabra 4y ago
Such gravitational force for sure, node_modules size is huge. Sorry.

WorldMaker 4y ago

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

AbraKdabra 4y ago

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

pjmlp 4y ago

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.