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.
With Bun, I have a single dependency which gives me: bundling, runtime, package management, test runner, SQLite, Postgres connectivity, S3 utilities, sane APIs (compare Bun.serve to whatever the heck I had to do in Node), routing…
Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps.
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)
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
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.
The unix philosophy pertained to simple composable limited cli tools. Most of which, at least the initial bunch, where written by the same handful of people, too, and one of each only: no several competing programs to awk and grep and cut and so on with widely different philosophies. At worst you had e.g. different implementations (like Sys V vs BSD vs GNU), and even that was already bad enough.
Once you get to programming language tooling, "do one thing and do it well" is not necessarily the best course, especially when you get leaking abstractions and limited interoperability and messy choices to make where no tool is standard.
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?
Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: 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.
> 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.
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.