It's weird their promotional video repeats "you can do <million things> without installing dependencies", if I want headless browser testing is that wrong to install a project that offers that?

Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality?

JS Runtime, Package Manager, Test Runner (both unit and headless browser), Bundler, JSX, PosgreSQL/MySQL/SQLite drivers, S3 client, Redis client, Formatter, Linter, etc.

Not to mention parsers for YAML, TOML, Markdown which are easily three separate projects worth of complexity in their own right.

I guess one clear downside is to get all these great features they're pushing for 1.4 you needed to wait until everything was ready. Given 1.3 was pushed out in October 2025, a 10 month release cycle across so many large technologies is tough. Before you give a pass because of the Rust rewrite Bun 1.2 was released in January 2025

I have to respect Jarred knows how to work the algorithm, 10 carefully crafted X teaser posts for this release spaced out over 72 hours https://xcancel.com/jarredsumner

> Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality?

It's funny because the top article on HN is about a malicious rust crate package, and people keep making comparisons to js/npm and how both language suffer from frequent security issues because they have weak std libs.

Its strange how flip floppy the JS ecosystem is, because go back literally 1-3 years or so and the BIGGEST complaint was the lack of a standard library and having to use a package for everything.

But now that Bun is actually doing it its somehow bad? Its also still open source, so those implementations you mention need dedicated teams can still get the attention they need by the community if needed.

I'm on the side that I'd actually prefer if node included more out of the box and we could drastically cut down on the number of packages we need due to the amount of supply chain attacks that happen on packages in the node ecosystem.

Ideally everything not built specifically for any given project is part of the OS or some other battle tested, supported system package.

For example, I might well choose to reimplement eg a subset of TOML parsing to avoid the dependency risk.

I don’t write JavaScript/TypeScript, but if I did, I’d find Bun’s “batteries included” approach compelling, at least to the extent I decide I can trust Bun, after due diligence

> It's weird their promotional video repeats "you can do <million things> without installing dependencies",

A couple years ago a common complaint was that the JavaScript ecosystem relied too heavily on dependencies for everything. Remember the left-pad incident where the developer deleted the popular dependency out of protest for reasons I can even remember? Or when colors.js was sabotaged to break everything that depended on it? The node-ipc package was sabotaged to delete files on developer’s machines. Then we had a wave of supply chain attacks that tried to insert malware into build scripts of popular dependencies.

So the ecosystem started moving toward more batteries-included style development in response.

It's faster to have it in the runtime in native code.

You have more options, not less, you can still use the external dependencies.

Out of the things you mentioned I think the following make totally sense to be included in a language runtime like this:

JavaScript runtime (obviously), package manager, test runner for unit tests, bundler, JSX, SQLite bindings, formatter, linter, YAML and TOML parsers. Maaaaybe even a Markdown parser and HTML5 parser. Definitely JSON, CSV and XML parsers.

I.e. similar to Python. Though Python is a bit of an incoherent mess. If you have all these you need them to be coherent.

Some of these feel like solved problems effectively, so having them in the standard library is nice (at the expense of keeping these forever for backwards compatibility once a new tech replaces it). I do think having a larger standard library for common things (like golang) is the way to go. If a dependency seems to basically be installed by default everywhere, maybe it should go in the standard library.

I always thought Bun's approach was to be the JS runtime with a large well-designed std-library, this isn't really new. It's nice to have a choice of a more or less-featured runtime depending on the project's requirements -- if size and complexity are an issue, there's a variety to choose from.

“ Why would I want everything reimplemented in this massive binary? “

This isn’t about what individual developers would want but what is most beneficial to Anthropic and claude code. They are likely using Bun as a vehicle for standardizing and enriching local user environments in order to address common tasks that claude generally writes bespoke scripts to accomplish.

I personally do not feel limited by the ~100mb binary size. We're working in Javascript after all.

Things like headless browsers are really annoying to include in FaaS environments, but are super useful. If they're in the runtime binary already, that'd be great.

I for one prefer batteries-included. Decision fatigue for every cobbled together package takes its toll. Having a single, trustworthy, good-enough solution for so many things makes my life easier.

I've still yet to run into any enterprise project using bun in the wild. It really feels like something entirely contained within startups that would choose wildly inappropriate tech like next.js.

Add in the influencer dev brainrot culture and you get these VC backed efforts to privatized publicly important projects (node.js) under control of quite evil people that have zero record of helping others.