Hacker News Reader

Comment by evilduck | Hacker News Reader

Yeah actually, Bun is also a bundler: https://bun.sh/docs/bundler

I wonder if Bun would already be past 1.0 if all the time spent doing the "bundler" stuff was instead spent on the runtime itself.

Did Jarred think that having a weaker variant of every feature in the Javascript world would somehow make it more attractive? Why was "bun build ..." considered better or necessary when there is `bunx esbuild ...`

https://github.com/oven-sh/bun/issues/159

I like that it's trying to be a faster Node, and the better native database drivers etc. Having a decent package manager alongside is also nice but anything else makes me question the long term vision/feasibility of Oven and Bun's maintenance.

`Bun.build` is a game-changer. They key is it is a fast and simple bundling _primitive_. You can use it to write your own `webpack-dev-server`, you can spin up 10 of them in parallel or series, with one api call. And it's only going to get better. It 100% made sense that Bun own this. Bun's plugins work for bundling and server runtime. Another example: for SSR, you can parse the AST of a file once, and re-use that for SSR runtime and bundling during dev. They key is that bundling is no longer this _heavy_ task that you spawn in another process, it can be as simple as function call.

Once you get it, you will realize how much of a game-changer it is. This is the reason Bun is going to win.

I like that Bun is going in the direction of a monolithic, self-contained binary. I'm sick of fiddling with tsc, ts-node, and stringing together 5 different build tools.

I'd rather install Bun, then get on with building our app.

Isn’t that like saying “glad Typescript exists but still prefer Flow?” One does a tiny subset of the other after all, and when you compare what Flow does to what Typescript does, I think it’s possible to argue quite well that the very tiny subset of what Typescript does is arguably comparable to what flow offers but that perhaps you might get basically everything that Flow offers and 100x more if you adopted typescript. And perhaps Flow might be better at several things but if it’s only really good at solving 5% of the total problem I’m going to pick the solution that also solves the other 95% even if the 5% Flow solves is just a mediocre solution

Note that I don’t really think that bun is the solution for everything or really that it is all that great. I am just pointing out that you are trying to compare two things that are not really the same thing at all. One is probably a strict superset of the other

I think their point is bun is not a runtime either because you can use it to spit out a blob of js that is run by the browser as normal. Which is how I use it to build js libs. Bun is then just the build and test tooling, and the various runtime bugs do not affect my downstream users (but it can impact testing).

Oh, people only use Bun as a build tool? Sorry, I thought it was being discussed as a runtime in the same land as Deno and Node. If it’s just a build tool, then parent comment is legitimate and I apologize. It’s weird though, when I google bun js the first thing it describes itself as is a “fast all-in-one JavaScript runtime”

Bun is a runtime like Deno that can be a drop-in replacement for NodeJs. It is ALSO a bundler like esbuild.

And a fricken great build tool because it speaks typescript, jest and bundling out of the box so you remove several layers of partially compatible tools (eg. Esm, jest and typescript don't really work that well together), yet still end up with a blob of js and the end so it's transparent to the browser end user

We can really muddy the waters:

Bun also supports Vite.

> We can really muddy the waters:

No we don't. Bun is not Vite.

Bun the package manager replaces npm/yarn/etc

Bun the bundler replaces esbuild/swc/etc

Bun the runtime replaces Deno/node/etc

( FWIW, they are right, Bun the _runtime_ can use the npm module Vite. https://github.com/oven-sh/bun/issues/250#issuecomment-16463... )

Well yes as a NodeJS runtime of course it can use npm. It doesn’t muddy the waters though is what I replied to.

Reply on news.ycombinator.com