4 ms·
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
by 698969 3y ago
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 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.
- grumblingdev 3y ago`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.
- vendiddy 3y agoI 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.