Quite a lot of people have told Jared (Bun’s Author) the same thing, but his opinion is that Bun should have everything a basic project might need. Keeping it in core he can make it more optimized than it would be as third-party library.
It’s a misguided approach according to me. And I feel Jared has become way too ambitious. But what can I say, it’s his passion project.
I can understand this vision: it's neat to be able to just open a file and start making a program, without having to choose one of the 20 relatively popular Postgres client libraries available on npm.
From the engineering standpoint, sure, it's a disaster.
But it's also the lost magic of TurboPascal and friends, where you could just be immediately productive, with no dependencies, no external tooling, on an old computer gathering dust in the school library.
> without having to choose one of the 20 relatively popular Postgres client libraries
They can easily provide official extensions/packages clearly namespaced and avoid all this mess. But I fear that they're more focused on a "headline-driven-development" approach, the more different from the status quo, the better
Not entirely switch, but so far I've been using bun for small side projects and it's been rewarding. There's a lot less project managing, some scripts can be just a single file with no dependencies, no package.json and no build chain.
Of the "batteries included" features, the `Bun.serve` web server and the `HTMLRewriter` HTML5 SAX API thing are very powerful, saving a lot of node_modules space.
Running TypeScript without a build step is neat. (I know there's `node --experimental-transform-types`, and it's great to see this feature propagated "upstream")
That said, for large established Node.js projects, I don't really see the pull to switch over to Bun. There's cost associated with it (for one, the built-in test runner works a bit differently, so if you're using `node --test` it'll require some fiddling)
It has just been a pretty low effort drop in replacement for me. It's definitely not a complete game changer, but quick iteration is just that bit more convenient since it's faster and I don't need to remember all the flags I normally have for my setup (Typescript, .env file, etc...)
No, thanks. That’s what Kotlin does and it’s an absolute shitshow. I want ‘editor index.ts’ and start working instead of going shopping for something that should’ve been part of std.
It's one of the things I love about Bun, I now write any non-trivial stand-alone scripts with TypeScript which is capable of a lot of functionality without needing any config or to install any external packages.
I like the batteries included option and would likely use it a lot. But not sure why they simply did not make a "batteries" package you could install on top of core and avoid the inevitable push back they knew they would get from this.
Deno is doing this. I'm not sure if it's good or not tbh. Now I have to worry about std package version on top of deno ver. And if I'm going to install a random package, how am I sure std deno is the best? Maybe I should choose something else. Back to decision fatigue
It’s a misguided approach according to me. And I feel Jared has become way too ambitious. But what can I say, it’s his passion project.