Bun 1.2 Is Released
bun.sh
bun.sh
Setting up typescript can be hard. Same goes for webpack, s3, postgres, jest and more. I also find the simplified file and stream access quite interesting.
Lets wait and see how a distributed deployment provider turns out.
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
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.
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.
https://lwn.net/Articles/776239
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.
Which feature are you referring to?
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...
No there weren't. It's just pure idiocy and incompetence.
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.
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.
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.
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.
It's cool that they're doing the mainstream thing now, but it's something for them to think about.
Regardless, the switch shows they pay attention and are willing to change.
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.
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.
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
A set of "blessed" known good packages would be wonderful to have in any language, I wonder why it's not a thing.
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...)
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)
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.
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 ;)
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.
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....
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
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
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.
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.
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.
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?
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.
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.
Finding documentation on that standard (particularly the edge cases) is very difficult
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
Thanks for the great work and bringing some much needed sanity in the node.js tooling space!
It's not new, has been the case for a few years, so honestly I don't get people complaining about next's complexity.
That means potentially no webpack, vite and their jungle of dependencies. It's possible to have bun as a sole dependency for your front and back end. Tbh I'll likely add React and co, but it's possible do do vanilla front end with plain web components.
IMO the main benefit of using their bundler is that things (imports/ES-modules, typescript, unit tests, etc) just behave the same way across build scripts, frontend code, unit tests, etc. You don't get weird errors like "oh the ?. syntax is not supported in the unit test because I didn't add the right transform to jest configuration. But works fine in the frontend where I am using babel".
But if you want to use vercel/nextjs/astro you still are not using their bundler so no better or worse there.
When you use new Response(s3.file(...)), instead of downloading the S3 file to your server and sending it back to the user, Bun redirects the user to the presigned URL for the S3 file.
That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
Response(file.stream())
> That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
I was initially excited about the project, but have no faith in the long term direction given the spurious (and often poor IMO) design decisions. At least as it's publicized on socials.
It would have been fine if they kept it v0.x, but releasing 1.0 should have significantly raised the bar for increasing API surface area
Even so, what would bother you about exposing the bucket? It's also a presigned URL so it doesn't have broad access utility.
I'd prefer an API like this where it's explicit:
Response((file(...).getPresignedURL()))
There's no immediate security hole, but I'd still be wary about exposing the bucket name, directory name and object name unnecessarily. Those might have a direct correspondence with the original public URL, but they might not. Maybe the object name is a database ID and the same ID gets used elsewhere for some other purpose. Who knows? Why take the chance if you don't need to?
I'd prefer an API like this where it's explicit
That's the thing, in the previous section it already described the "s3.presign()" function. If you want to redirect to a presigned URL, you already have everything you need, no magic required.
The more I look at recent bun developments the more it seems like they’re shooting for magic rather than intelligent design.
It’s clearly impressive stuff and I’m glad they’re doing what they’re doing, but stuff like this makes it so I’m hesitant to commit to the runtime APIs.
But it has to be to a certain degree, maybe S3 is too far, but SQL drivers makes sense - but again, to which degree? There are _many_ databases out there, should there be drivers for half of them? Even at that level it's a lot of added code which means slower executable.
Also, I think Bun is missing out on security by adding such sensitive APIs to Bun, imagine bun taking all your source files and uploading it to your private S3 due to some script or path issue that allowed eval to run! It's game over right there.
Point is, who is responsible for maintaining the Lib and how do you change the Lib when SQLite changes. There might be a bug in SQLite. How do you fix it in Bun? Which versions receive a fix? How do you handle that a parch of your runtime (Bub) now might change behaviour of code running on it (because users worked around it)?
These are solvable issues, to some degree and with some downsides. However, at some point you stop being a runtime and start being a platform, which will bring other resposibilities and issues with it.
Does it? Legitimate question. I would've assume that this could be almost entirely negligible depending on how the code is loaded into the runtime. If the code being loaded is only triggered when an import statement is seen, wouldn't that lead to essentially no speed overhead?
Even if it was statically linked in, I don't see why having the code would slow down the executable by any amount that we'd want to consider. Maybe literally more of an executable to load into memory, but I don't see that being a tangible slow down.
Would love to know if I'm missing a big piece here though.
> article literally provides benchmarks, where bun is twice faster than fastest Node.js solution
I'm told their dev experience with Bun is out of this world bonkers good because of speed and simplicity.
Dev experience can play a big role long term. If your codebase and/or process sucks, you'll lose good people unless you pay FAANG tier compensation.
From a project management perspective I'm a little confused why would you spend time on S3 support while you're still not 100% Node.js compatible. Next.js is a very big ecosystem and if you can get Next.js customers onboard you'll grow much more than supporting S3.
This assumes you know what the project(s) is/are. Also the people working on it aren't robots. Maybe certain things take time to figure out and meanwhile you can do something else? It's also not just 1 person on the task.
> if you can get Next.js customers onboard you'll grow much more than supporting S3
Towards what? That doesn't make $$$. This is VC-backed. The goal isn't to provide Bun for free and gain all the users in the world.
100% compatibility is a nice marketing win, but the long tail of compatibility may not make much difference to the average user.
What percentage of the total Node.js API surface area do you actually use in your day-to-day? How many weird edge-cases therein are you actually depending on?
I’m impressed
The dumbest thing I saw was Amazon’s CDK library looking for specific package manager lockfiles and was therefore semi-incompatible with bun
But if you use SST it doesnt matter
I find this entry pretty funny. Who even asks for this and what makes they think it's worth writing code for.
Especially that it is written in Zig, which is very memory unsafe. I mean if you refer a variable that is not alive anymore, it just accesses some random unrelated memory instead of segfaulting (in debug and safe mode too)[0]. How hard would it be to bolt a memory liveness system above it, that flags a variable name dead and blocks access to it, if it is dead? No, "just don't write UB"[1].
Anyway I'd certainly not put a Zig made anything facing the internet, especially not a webserver.
[0] : https://news.ycombinator.com/item?id=41720995 [1] : https://github.com/ziglang/zig/issues/16467#issuecomment-164...
That being said, all of these run times use a JS JIT that are written in a memory unsafe language, that emit and execute raw machine code. They frequently have vulnerabilities.
Edit : It is
To get started, pass an HTML import to the static option in Bun.serve:
import homepage from "./index.html";
Bun.serve({ static: { "/": homepage, },
async fetch(req) {
// ... api requests
},this is amazing and so cool thanks a lot !!
Serving a static file isn't exactly new, so I feel like I must be missing something.
They have a plugin api, but honestly I don't like the sound of "framework-specific plugins". It is because of this, all front-end frameworks are now a mini compiler (inside a bundler/compiler) and being too comfortable now to come up with new wacky syntaxes. I prefer frameworks to just be frameworks and being able to write normal typescript.
But for a large project, I'll happily trade a compilation step for the tools modern frameworks provide for managing complexity.
It actually mentions HMR at the bottom of the docs, and I see plugins are already available. So while it can't currently replace my Vite stack for most projects, it seems like it eventually could.
I'm not sure how I feel about this sort of coupling in general, but for small projects it could be very convenient (as you mention).
I liked this approach because I actually wanted to create very simple / static serving in bun and I had to actually do a lot of hoops like reading it from Bun.file() and then some things more
Its just nice that its now solidified into the standard library / behaviour I suppose
I've since tried it with new JS/TypeScript Projects which also makes use of its built-in Bundler [3] and testing support [4], installing deps is also instant. Having everything work OOB, fast, are real quality of life improvements where Bun has now become my first choice for any new JS project.
[1] https://bun.sh/docs/runtime/shell
[2] https://bun.sh/docs/api/sqlite
On the other hand Bun worked right out of the box. I had spent 10-30 minutes futzing around with node-ts or whatever the tool is to run TS “directly” on the CLI and I was dealing with the all the dreaded messages “not a module”, “can’t use import/require”, “ESM/CJS” and trying all the normal fixes (changing package.json module type, changing tsconfig, changing the way import/require) all to get a ~200 line script to run. I switched to Bun as a Hail Mary and it worked wonderfully.
node --experimental-strip-types index.ts
On non-latest Node tsx package worked great for me (as oppposed to ts-node)
But both of those options just throw away type information (and so does Bun)
This is the standard in every web framework like Rails and Laravel, and the JS ecosystem will really benefit from this. The next steps are migration and schema management and a better out of the box testing story (w/ nice way to setup factories)
It seems they just drafted a new release to communicate the groups of change from the previous releases.
If you're worried about binary size from features you don't use: the binary size cost of Bun.sql is less than 50 KB (you can check this yourself via the .linker-map file in the *-profile.zip builds of Bun or via https://bloaty-csv-reader.vercel.app which was a tool I wrote a little while ago to see how much space various features of Bun use)
If you're worried about runtime overhead, practically everything in Bun is lazily loaded. So if you never access Bun.sql or Bun.S3Client, it will not load it. And, even if it does load it, because we implement it in native code and worry about this a lot, it doesn't really cost much to load.
I don't know about all the reasons, but personally I stay away from projects who try to bundle in as much functionality as possible into one "all-in-one" thing. I prefer approaches where you yourself chose the right library for the problem at hand, as it tends to be that different libraries have different tradeoffs, and I want to chose those tradeoffs myself. Summarized as The Unix Philosophy or "do one thing and do it well" I suppose.
I'm not saying it's wrong of Bun to include those things, their value proposition is the "all-in-one" approach, which a large group of people seem to like, so seems they're doing right by their audience.
But again, personally I don't like the tradeoffs involved with that approach, but I wouldn't try to convince Bun either to go against their explicit goals.
And like diggan said here, I like tools with focus, for example I choose to use one note taking app, one separate app to write code in, another app to chat with, and yet more apps for things like email, and SSH even though they are all text-centric apps and could be bundled into one and the same.
It's for the same reasons that I switched to biome. It's faster and reduces total dependencies. I very happy with this combo.
Is there more code tooling (linting, formatting, etc.) on the roadmap for bun, or are you focusing on the runtime features?
Batteries included is the way to go. I hope the battery gets larger and larger and you also keep up the quality.
- extremely happy bun user
Instead of having to tinker with my package.json, tsconfig.json, etc. to get everything just right, it works right of the box the way you expected with `bun init`.
Then it's just `bun run index.ts`.
And it's fast!
Node is great but there's just too many options to configure. I appreciate that Bun went ahead and made a bunch of assumptions and pulled commonly used stuff directly into it.
What exactly do you have to configure in Node?
As far as I know, it requires some non-standard usages in TS code, like adding the .ts extension to your imports at the top of your TypeScript files. It doesn't support .tsx files or any TypeScript feature that requires more than type striping. The initial support is appreciated, but it's not on part with Deno or Bun yet.
TL;DR you will still need to work on adding proper TypeScript support anyway, compared to Bun.
> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
There's nothing to gain from a different versioning scheme. People just want 1.0 and this is just another way to ask for it.
It'll be done when it's done.
Python certainly isn't stable, for example. (And likely never will be, the devs just don't care.)
In the end, it's all JavaScript (or TypeScript if you like Kool-Aid), as long as you know the language you can pretty much effortlessly jump between node, bun and deno, they're more similar than they are different :) Migrating projects on the other hand, well...
Most of my production code ends up ClojureScript for frontend stuff.
That's cool that you get to write front-end code in an interesting language though! How long have you been doing that? How big is your team? I feel like larger teams tend to have more boring choices of software
After reading through this thread, I'm personally leaning toward Deno for my first non-Node project. Demo seems to be more thoughtfully managed, more pragmatic (e.g. Node/NPM compatibility), more secure, with better technology choices (e.g. Rust vs. Zig) overall.
> more pragmatic (e.g. Node/NPM compatibility)
Both projects are good on this front. Deno actually originally explicitly promised NOT to work on node compatibility to "move the industry forward". They realized this was a failing move and backtracked (which has been a little controversial amongst the core base)
> with better technology choices (e.g. Rust vs. Zig)
I think it's a little silly to take the choice of language as a "technology choice". Both are new languages, both still have a lot to prove, and both have pros and cons the other lacks
Bun is miles better in this regard.
Deno initially did not even want to focus on Node/NPM compatibility, and then backtracked once they understood the importance of it.
Bun OTOH runs the entire Node.js test suite on every commit, and the mentality of breaking less existing node/npm code is clear. e.g, just in this release, `bun publish` has the exact same CLI as `npm publish`, and bun also works out of the box with .npmrc.
About the Node.js test suite.. many modules are at 100% compatibility, and many are at 90%. You can track it here: https://bun.sh/docs/runtime/nodejs-apis
Also, they reimplement the V8 public C++ API in JavaScriptCore (!) so that packages like npmjs.com/cpu-features work [1]
Every new feature has this aspect to it, e.g the postgres client inbuilt is a drop-in replacement for the `postgres` package.
As far as Node/NPM compatibility, and thought given to compatibility in general, is concerned, there is absolutely no contest.
And if I'm allowed a little snarky slight... Deno couldn't even maintain compatibility with their own API for reading and writing files during the Deno 1->2 update.
[1]: https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v...
Sounds like something they should try upstreaming?
Now they'll need to track all the tests to manually modify/import...
Other stuff, like the C interop and psql client sounds amazing as well.
I'm currently only using Bun for smaller sideprojects where I'm also trying to use some of the more out-there features, and it has been a blast so far.
Though the most important question for me (as always with these announcement videos): where can I get a bun plush?
Looks like you’re right. Thanks for clearing up my misunderstanding: I’m not sure why, but I thought Bun was using a custom JS implementation.
It is a bit manipulative advertising to draw hype people in I would say. You know those tech influencers who like to peddle stuff to get views.
edit: I was a bit unfair, it feels like those "hype tech influencers" are the ones who downplay JSC in favor of promoting Zig, not the project itself. The frontpage of Bun mentions JSC twice and Zig once.
I think it is a bit faster. But a lot of Bun's speed comes from implementing API's in Zig rather than JS (which node does a lot)
Can anyone speak to how much adoption it's getting professionally? Even anecdotal points are useful. When v1.0 was released I briefly tried testing it out in my employer's monorepo. It unfortunately wasn't a drop-in replacement and we hit compatibility issues/couldn't invest time debugging. While we could have migrated smaller projects to it, we decided not to split our tooling and just stuck with pnpm.
Curious if others have had a different experience!
The only issue I hit is that Vercel only runs node, so builds that may have passed on bun, sometimes fail on Vercel. So just before I deploy, I run `npm run build` to catch any node-specific build issues and fix them before Vercel finds them.
I hope Vercel will add support for bun in their edge runtime.
I aim to have an "upstream first" policy when it comes to patching/forking dependencies.
And fun fact about GitHub, you can append .patch to a PR url or commit URL to get a patch file.
This makes patches self-documenting (they literally are a link to the upstream PR) if the tool can fetch remote patches. Nix is the only tool I'm aware of that makes this easy.
Maybe I should try dual-booting with Ubuntu.
Still a lot of open/recent Windows issues: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
Bun seems to be a little inspired by the Go language design. It is batteries included and it has a substantial stdlib. Integrating something like an S3 SDK - what I would consider to be a high level feature - seems like an interesting choice, but makes a lot of sense considering Bun specifically targets cloud environments
package-lock.json
yarn.lock
deno.lock
bun.lockSome of us work across multiple projects and aren't up in our arms about what package manager the current project use. Some days you touch 3-4 projects that happen to all use different package managers.
Let me explain: projects usually support only one package manager. In a world of N competing JS package managers, you need to ban lock files from N-1 of them.
It installs npm packages, it executes JS and TS code, it bundles code for front end, it runs tests. Plus it has a lot of random pieces related to this development, like integrated database access.
Compare it to node, npm, webpack, and jest, all in one, and whatever the guy dreams of. It's certainly fast and offers great DX, but I wouldn't bet on it to stay around for, say, 5 years.