I think this position is also one of the reasons it gained attention. Batteries included is a popular and chosen route for many.

nothing wrong with that, but why putting it on a global object instead of a built-in module. Better yet, that module may be publishable on jsr/npm

> Setting up typescript can be hard.

Node just enabled it by default. You still need the dev dependency for manual compilation and checks, but at runtime it should "just work". https://nodejs.org/en/blog/release/v23.6.0

As enthusiastic as I am about node's typescript-support, calling it "just works" is a bit of a stretch. Not entirely sure if it's still the case anymore on the latest versions but last I checked it was required to use `.ts`-suffixes for all the imports, something a standard typescript project will hardly ever have and needs to be specifically configured to be considered valid syntax (allowImportingTsExtensions:true).

But yeah, there's progress, and once this gets solid traction (which I'm sure it will) it might finally be the last drop in the bucket to convince TC39 to stop being so antagonistic to having some notion of type-support directly in Javascript.

> but at runtime it should "just work"

Maybe when it doesn't use WASM and there's proper integration. Otherwise it's just like npm and people still need to look for alternatives.

Which means they did not learn from Python's mistakes. You need to look further than the next couple of years. For some reason during the past 10 years or so it has become fashionable to throw away everything the industry has learned in decades prior and start anew, repeating the same mistakes. We'll never turn into proper engineering with such attitude.

https://lwn.net/Articles/776239

https://lwn.net/Articles/888043

https://lwn.net/Articles/790677

This doesn't seem like a mistake other than how it is the obvious lead to the scope creep, maintenance creep pipeline. Python having an highly capable standard lib is exactly why some people love it, specially "10 years ago" when it was very slow to rev up your machines that need to be very much isolated from other machines, and you just had to have a bright enough person on systems making sure everything was included from the get go. Python saved the ass of more than 0 people reading this discussion right now on that merit alone.

I think there's a simple solution to all this. Libraries targeting third party protocols get an expiration date and have to forcefully be replaced by name after a given number of versions. Even if they keep the same underlying code, still change the name to force developers to look up its usage and legacy. How many versions? However many equates to the threshold you use to call most systems "legacy". I don't mind some job security and some timebomb punishment aimed at dinosaurs. I have bigger and more consistent issues with that than with weter or not C++ let's me crack a .rar without extra libs.

> during the past 10 years or so it has become fashionable to throw away everything the industry has learned in decades prior and start anew

This is a curious take to me. I've spent the last 10 years seeing people claim again and again that if JS just had common stuff built in like <other lang>, we wouldn't have all this library churn, node_modules bloat, and left-pad silliness. That the mistake was not including a standard library.

This is mostly a sentiment I see from people who used or heard of JS 10+ years ago and didn't bother to learn added JS language features and recent tooling.

Standard libs can be great, but they should really be reserved for baseline features, especially in a language like JS where all changes must be backward compatible. The standard JS has now is not at all what it was in the early 2010s, it's a very good set of baseline features.

The opinionated batteries-included stdlib was exactly what made Python popular in the first place though (and even despite its 'weird' syntax). And tbh, most of the current problems were also only added in the Python 3.x era (e.g. 3.x looks very much like a 'second system' - https://en.wikipedia.org/wiki/Second-system_effect)

Python's "mistakes" are my weapons in my restricted corporate production system.

Batterie-included is one of the main things that made python great and useful before it became big enough to not need it (don't know for bun).

I despise Python's tooling and never touch it willingly.

That said, Python's 'mistake' also made it one of the most used languages ever. For nearly 2 decades, you could just type `python` in terminal and get rolling, and that was invaluable.

The only real 'mistake' that Python did was breaking backwards compatibility so spectacularly that single greatest feature was rendered useless.

> single greatest feature was rendered useless.

Which feature are you referring to?

being able to type `python` and start writing a program that would work nearly everywhere.

With compatibility break there was a decade of confusion, even the simplest print statement wouldn't work. I understand there were real reasons to do all that, but it did cause damage.

Steve Yegge put it better than I can[0]:

> the thing is, every single developer has choices. And if you make them rewrite their code enough times, some of those other choices are going to start looking mighty appealing. They’re not your hostages, as much as you’d like them to be. They are your guests. Python is still a very popular programming language, to be sure — but golly did Python 3(000) create a huge mess for themselves, their communities, and the users of their communities’ software — one that has been a train-wreck in progress for fifteen years and is still kicking.

> How much Python software was rewritten in Go (or Ruby, or some other alternative) because of that backwards incompatibility? How much new software was written in something other than Python, which might have been written in Python if Guido hadn’t burned everyone’s house down? It’s hard to say, but I can tell you, it hasn’t been good for Python. It’s a huge mess and everyone is miserable.

[0] https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

> there were real reasons to do all that

No there weren't. It's just pure idiocy and incompetence.

Well, I would agree with you. But I'm no language designer nor maintainer. It could all be bollocks, but since I'm the ignorant one, they get benefit of doubt.

As most things do, it cuts both ways. Rust suffers from their very slow adoption of libraries into a standard library, imo.

"mistakes"

https://www.tiobe.com/tiobe-index/

A thing can be both a mistake from maintainance perspective, but a great boon from user perspective, or even a horrible kludge from power user perspective.

Batteries included mean wherever there is a fully compliant implementation, there is something available, even if it isn't the best solution in the galaxy.

Whereas the best solution in the galaxy might only work in a few selected planets, in other ecosystems without batteries.

I prefer batteries included, and not having a culture with a function per package.

golang is also battery included which seems great. i hope lua can have something similar though smaller

I think their move away from a binary lock file to a text based lock file in this release makes this pretty clear - they shoot first and ask questions later. Any of those problems they've identified with the binary lock file are kinda obvious if you think about it for a bit. A strong indicator that you should think about it is that the popular languages with package managers (npm, ruby, rust) have text based lock files. The fact that the bun team didn't think about it and thought that binary was better because it was faster and no one had thought of this idea feels like hubris to me.

It's cool that they're doing the mainstream thing now, but it's something for them to think about.

Or they think extensively about performance.

Regardless, the switch shows they pay attention and are willing to change.

This is for their managed offerings. The problem of VC backed software was always that there would be these integrations that'd try to provide something unique to it, or IOW, lock-in.

What’s the monetisation plan

Since at least web2.0 I've been burned many times. So my default position on VC backed projects without clear monetization plan is that it is probably bait-and-switch.

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

And it's successful! I've unironically learned about Bun on YouTube, and now am a happy user. :)

A set of "blessed" known good packages would be wonderful to have in any language, I wonder why it's not a thing.

I'm wondering what made you switch ? I find the ubiquity of node very comforting, maybe I'm not seeing the argument that will convert me over ?

Not the original commenter -

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

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)

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.

Being misguided or not, it is good to have different approaches, including the ones that doesn't work.

Bravo, let a hundred flowers bloom. May the best ones win, or at least prove themselves to be "worse is better".

I think it's great. There are already alternatives so makes sense for Bun to do its own thing

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

As long as it works and follows a consistent API, why would that be an issue?

I kinda like the idea of not having to import potentially very slow JS code to do things that I need in basically all my projects.

The interesting question is: Where do you draw the line? Should a HTTP server/client be in the stdlib? File access? String templating? And why not a window system, 3D API and UI wrapper?

IMHO a stdlib should mainly provide standardized interface types, but not necessarily the implementations behind those interfaces. But that's probably not a very popular opinion since it falls between the two existing options of having a very bare bones and a batteries-included stdlib ;)

> Wouldn't that be better as an optional library?

Totally agree.

In their words, "Bun aims to be a cloud-first JavaScript runtime. That means supporting all the tools and services you need to run a production application in the cloud". This doesn't give me a lot of confidence.

This particular design choice seems even worse than Node.

> This particular design choice seems even worse than Node.

We could argue that it's worse/better, but in the end it's just different. NodeJS when it appeared had the vibe and "marketing" to be something lightweight, fast and event-driven (compared to the alternatives at the time at least), where the 3rd party ecosystem provided the tooling for what Bun now tries to bundle into their "all-in-one" tool.

We've seen the same cycle multiple times. Developers need flexibility to configure something so a flexible solution appears, everyone gets excited and starts migrating. Eventually, more developers are tired of the flexibility and don't understand why there are so many configuration-options, so eventually a "all-in-one" solution appears, everyone gets excited and starts migrating. Eventually, people need to be able configure more things so....

Just wait until they give preference to services that their VC benefactors are also supporting.

it is a very bad idea. you start your project using the built in client libs, you are locked in to bun as js runtime. if the license changes you are stuck.

Not only that, but when the new hot JS runtime inevitably drops, it's going to be a pain to move to that.

What "new hot JS runtimes" are you talking about? Node has been pretty stable for over a decade and a half. This is the first time that anything is even challenging that place. It just so happens that both Bun and Deno efforts started around the same time and now have to compete with each other

I think any competent company would be savvy enough to avoid lock in for a technology with adoption this low. I don't think that's what these features are aiming for. I think they're aiming for the young dev starting side projects that wants to get up and running quick. Or imagine teaching a bootcamp class and you want a tool that will do some magic for you so you can focus on explaining other complex aspects of web development

You don't think they're trying to lock us in? What's their big monetization plan then? I think they want us to drink the Kool aid. I don't have a problem with it though because I'm small enough that I can still refactor the world in a few days if I really need to.

AFAIK bun is VC backed, so they need to make money at some point, therefore a speculation:

They want to make bun an all in one runner in order to vendor lock you in somehow. But I might be wrong. It indeed does not make sense to put such dependencies in the core/std lib

I think that's the plan too. But I'm still not fussed about it. At the end of the day, it's still a great tool for getting stuff done and one less decision I have to make.

Also.. I don't quite know how they're going to lock me in unless they mess with the license. I can deploy my own bun server anywhere, no? I'd be stuck on bun I guess but still not paying anything.

Those packages exist already though. Pretty sure the bun maintainers (or Ciro Spaciari in this case) asked the question "how fast could it be if written in zig?".

Isn't it possible to write it in Zig as a separate extension? Every mature language I'm aware of supports this AFAICT

Tree shaking means it won't bother you if you don't use it

>Wouldn't that be better as an optional library?

It would be better if the libraries were not the most optimal or good enough. In bun's case it is not just the minimal they are basically making everything as good as it can be.

s3 is pretty much a de-facto standard, just like json like or not. Postgres also makes sense, it is the most widespread and community-liked db. What is the point of "optional libraries" tbh? It was a PITA in PHP back in the days and very inconvenient, prob most devs would prefer this way.

I feel like HN is on cognitive dissonance, they complain JS projects having too many dependencies and they also complain now when things are more integrated into the runtime because it increases vendor-lock and few extra megabytes (actually kilobytes according to the devs) to the binaries :/.

Lastly, big companies also prefer less dependencies, it is not just devs.

It probably looks very wrong to people who still think lots of "modularity" and small packages is a good thing.

I'm all for it, and lots of Bun APIs are purely practical. Bun.stringWidth, for example, exposes code Bun already has internally. Nodejs probably has the same thing, but instead of us being able to use it, it gets reimplemented in 10 different versions in node_modules. How is that better?

I doubt the Bun team will have to change the S3 code very much over the years. The test runner, bundler, Postgres client, sure, I can see those being harder to maintain. But I'm also tired of everyone assuming everything needs to change all of the time. DX aside, my team is still on Webpack and we've only needed one new feature from it in the last ~5 years. Why can't Bun's bundler reach maturity and only receive a few updates?

Node does have the same thing, and you can access it with `--expose-internals` from `const { getStringWidth } = require("internal/util/inspect");`. They don't expose it for some reason.

I'm also still using webpack. Not sure why the community abandoned it. Haven't had any issues. Everything seems to use babel under the hood anyway and they all have their little wrappers over top.

> s3 is pretty much a de-facto standard

So was XML before, and SGML before it. De-facto changes over time, and backwards compatibility means your decisions are cast in stone.

In 20 years, you could see s3 being abandoned for newer formats, but bun will have to keep those packages.

So? I mean, what ist the real downside, beside 5kb additional filesize?

Assuming backwards compatibility.

Ongoing maintenance burden. Ever increasing API, mistakes set in stone, subpar performance or properties.

"Standard library is where libraries go to die." exists as a saying for reason.

> s3 is pretty much a de-facto standard

Finding documentation on that standard (particularly the edge cases) is very difficult

Back in what days of PHP? I've been using PHP and MySQL since... Probably 2003ish and never had a problem. I think you need the extension but most providers had it.

that's old school javascript mentality. new school is bake it all in and let people get to work on the interesting bits.

I'm sure in the short term people will be happy, but maintaining that in the long run is a footgun. I can't see a team big enough to achieve that correctly, especially the bug confusion (e.g: is it bun or the 3rd party issue) that will creep on the main repo.

I think it makes it easy to provide paid hosted services later if needed.

Hypothetical example: S3 client built in, enable a flag and now get a dashboard seeing analytics around file downloads, download latencies etc

Just pure hypothesis on my end given they have to make money somehow at some point

I don't like it either but in practice it doesn't really matter. Tree-shaking means those unused features won't affect your project

Except that you can't shake built-ins. It's in the bun binary.

So? IT wont affect performance. Dont call the library and ITS egfectively unused Code in the binary.

I'm not the one complaining. I'm just saying this has nothing to do with tree-shaking.