Hacker News Reader

Hacker News

Comment by arendtio | Hacker News Reader

Parent Full thread

arendtio

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

View on HN

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

Sir, 2010 was 16 years ago.

And you're already not getting hired because they're not on your CV.

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

What are the benefits, though?

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.

This:

    node + npm + vitest + vite

Turns into:

bun

That's the benefit

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

To say nothing of `bun install` being about 50 times faster than npm, and disabling most post-install hooks by default.

>Can't we just go back to node + npm + vitest + vite?

The mere enumeration shows how bad it is.

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)

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.

Well, do one thing an one thing good as in Unix philosophy?

- Runtime

- Package manager

- Test runner

- Build tool

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.

At the worst case you get this: https://xkcd.com/1987/

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?

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

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

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

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.

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

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.

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?

pnpm is generally safer and had the age delay much sooner than npm as well.

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.

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

Reply on news.ycombinator.com