9 ms·

Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?

by arendtio 2mo ago

rapind 2mo ago
At this point, I'm not sure anyone should still be using npm.
- deleted 2mo ago
  [deleted]
- quantummagic 2mo ago
  Seriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised.
  - arendtio 2mo ago
    But isn't this a problem with the ecosystem and not with the program? I mean, with yarn / etc., you have the same problems, don't you?
    - rapind 2mo ago
      pnpm is generally safer and had the age delay much sooner than npm as well.
andyfleming 2mo ago
There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun. https://nubjs.com https://nubjs.com
- kachnuv_ocasek 2mo ago
  What are the benefits, though?
  - dhamidi 2mo ago
    This: node + npm + vitest + vite Turns into: bun That's the benefit
    - Octoth0rpe 2mo ago
      Throwing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph. People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation. Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions https://www.npmjs.com/package/sharp?activeTab=versions)
    - stevefan1999 2mo ago
      I rather replace bun with deno, given that now both bun and deno are written in Rust, and Deno have even more node compatibility than bun. Deno and Node both runs on V8, while Bun runs on JSC, and Deno has a killer feature that you don't have to even run npm install to use package, you can just top-level import or await import an URL (given that you allowed it with a command prompt or bypass it competely with -A but discouraged). I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json
    - chuckadams 2mo ago
      To say nothing of `bun install` being about 50 times faster than npm, and disabling most post-install hooks by default.
    - deleted 2mo ago
coldtea 2mo ago
>Can't we just go back to node + npm + vitest + vite? The mere enumeration shows how bad it is.
- mnahkies 2mo ago
  I think it's a pretty reasonable split of responsibilities, and not uncommon. Eg: JDK + maven + junit + tomcat Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)
  - all2 2mo ago
    Is this the old monolith vs micro-services argument? I guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on. I'm not sure I'm slicing this along the correct abstractions, though.
- tavavex 2mo ago
  Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
  - coldtea 2mo ago
    >Why? Is fewer things always better? Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: https://xkcd.com/1987/ https://xkcd.com/1987/ >Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better? Taking it to an extreme, why not? If it was just a tool that did everything for a language (compile, dependencies, formatting, linting, debug, profile), I'd be totally OK. I'd also be ok with a handful of different tools, all by the same team/project, with the same shared vision and interoperability in mind to begin with. Go got quite close with that.
epolanski 2mo ago
Node is too slow, plain and simple. I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.
virajk_31 2mo ago
Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.
- 52-6F-62 2mo ago
  And you're already not getting hired because they're not on your CV.
- speedgoose 2mo ago
  Sir, 2010 was 16 years ago.
paxys 2mo ago
Every new framework gets buzz on HN and is forgotten a day later. Meanwhile 99% of developers never left node + npm + vite in the first place.
root_axis 2mo ago
> Can't we just go back to node + npm + vitest + vite? You're kind of stating the reason for the buzz there: one runtime that does everything you need rather than cobbling together a dozen different tools. Not that there's a problem cobbling together different tools made to do a job, each tool has a purpose and solves a problem, but having all problems solved out of the box is very convenient. Bun does offer an additional major advantage, i.e. the bundler has a runtime API, so the same process that serves your assets can also bundle them in memory without having to coordinate an external bundler writing static files to disk.
rk06 2mo ago
node is used in prod and bun is faster than node. so using bun directly translates to lower cogs

Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?

rapind 2mo ago

At this point, I'm not sure anyone should still be using npm.

deleted 2mo ago
[deleted]
quantummagic 2mo ago
Seriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised.
- arendtio 2mo ago
  But isn't this a problem with the ecosystem and not with the program? I mean, with yarn / etc., you have the same problems, don't you?
  - rapind 2mo ago
    pnpm is generally safer and had the age delay much sooner than npm as well.

andyfleming 2mo ago

There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun. https://nubjs.com https://nubjs.com

kachnuv_ocasek 2mo ago
What are the benefits, though?
- dhamidi 2mo ago
  This: node + npm + vitest + vite Turns into: bun That's the benefit
  - Octoth0rpe 2mo ago
    Throwing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph. People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation. Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions https://www.npmjs.com/package/sharp?activeTab=versions)
  - stevefan1999 2mo ago
    I rather replace bun with deno, given that now both bun and deno are written in Rust, and Deno have even more node compatibility than bun. Deno and Node both runs on V8, while Bun runs on JSC, and Deno has a killer feature that you don't have to even run npm install to use package, you can just top-level import or await import an URL (given that you allowed it with a command prompt or bypass it competely with -A but discouraged). I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json
  - chuckadams 2mo ago
    To say nothing of `bun install` being about 50 times faster than npm, and disabling most post-install hooks by default.
  - deleted 2mo ago

coldtea 2mo ago

>Can't we just go back to node + npm + vitest + vite? The mere enumeration shows how bad it is.

mnahkies 2mo ago
I think it's a pretty reasonable split of responsibilities, and not uncommon. Eg: JDK + maven + junit + tomcat Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)
- all2 2mo ago
  Is this the old monolith vs micro-services argument? I guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on. I'm not sure I'm slicing this along the correct abstractions, though.
tavavex 2mo ago
Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
- coldtea 2mo ago
  >Why? Is fewer things always better? Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: https://xkcd.com/1987/ https://xkcd.com/1987/ >Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better? Taking it to an extreme, why not? If it was just a tool that did everything for a language (compile, dependencies, formatting, linting, debug, profile), I'd be totally OK. I'd also be ok with a handful of different tools, all by the same team/project, with the same shared vision and interoperability in mind to begin with. Go got quite close with that.

epolanski 2mo ago

Node is too slow, plain and simple. I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.

virajk_31 2mo ago

Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.

52-6F-62 2mo ago
And you're already not getting hired because they're not on your CV.
speedgoose 2mo ago
Sir, 2010 was 16 years ago.

paxys 2mo ago

Every new framework gets buzz on HN and is forgotten a day later. Meanwhile 99% of developers never left node + npm + vite in the first place.

root_axis 2mo ago

> Can't we just go back to node + npm + vitest + vite? You're kind of stating the reason for the buzz there: one runtime that does everything you need rather than cobbling together a dozen different tools. Not that there's a problem cobbling together different tools made to do a job, each tool has a purpose and solves a problem, but having all problems solved out of the box is very convenient. Bun does offer an additional major advantage, i.e. the bundler has a runtime API, so the same process that serves your assets can also bundle them in memory without having to coordinate an external bundler writing static files to disk.

rk06 2mo ago

node is used in prod and bun is faster than node. so using bun directly translates to lower cogs