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