Bun 1.2 Is Released
106 comments
·January 23, 2025Karupan
herpdyderp
How does bun make a difference in the frontend tech stack that you mentioned?
DanielHB
Last I tried (several months ago) it didn't, the built-in frontend bundler was not very useful so everybody just used 3rd party bundlers so (for most people) it would not have any meaningful differences compared to nodejs. It seems they are putting more effort in the bundler now, so it seems like it can replace plain SPA applications just fine (no SSR). The bundler is inspired by esbuild so you can expect similar capabilities.
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.
nsonha
not up to this point, but with this release, bun is now a bundler.
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.
cal85
Bun has always been a bundler (and package manager, and Node runtime). This release adds "HTML imports" as a way to use the bundler.
Raed667
i have been setting up these react/ts/etc project with vite or next.js, just fine , i think you're underestimating how much progress happened in other tooling as well
nsonha
Idk about next 15 but you can literally bootsrap next 13 using a single index.tsx with typescript & next being the only 2 dependencies in package.json. No typescript is fine too.
It's not new, has been the case for a few years, so honestly I don't get people complaining about next's complexity.
Cthulhu_
Why are they putting 3rd party (databases) and external (s3) librares into their core / std lib? Wouldn't that be better as an optional library? I think a runtime like this should be very, very careful with what they put into the std lib, adding these already makes it feel like a kitchen sink project.
jbergstroem
I think this position is also one of the reasons it gained attention. Batteries included is a popular and chosen route for many.
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.
homebrewer
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
libwithttl
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.
flohofwoe
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)
Rucadi
Python's "mistakes" are my weapons in my restricted corporate production system.
spiffytech
> 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.
poulpy123
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).
e3bc54b2
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.
null
viraptor
> 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
Shacklz
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.
re-thc
> 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.
nsonha
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
skwee357
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
jeswin
> 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.
diggan
> 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....
shubhamjain
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.
animuchan
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.
Raed667
> 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
meiraleal
Being misguided or not, it is good to have different approaches, including the ones that doesn't work.
lioeters
Bravo, let a hundred flowers bloom. May the best ones win, or at least prove themselves to be "worse is better".
gardenhedge
I think it's great. There are already alternatives so makes sense for Bun to do its own thing
supriyo-biswas
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.
zaphirplane
What’s the monetisation plan
timeon
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.
sod
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?".
izietto
Isn't it possible to write it in Zig as a separate extension? Every mature language I'm aware of supports this AFAICT
ksec
>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.
Aeolun
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.
Imustaskforhelp
HTML imports In Bun 1.2, we've added support for HTML imports. This allows you to replace your entire frontend toolchain with a single import statement.
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 !!
sampullman
How does this allow me to replace e.g. Vite? Is there a way to do hot module reloading, css pre-processing, or load framework specific plugins (like the Vue SFC compiler)?
Serving a static file isn't exactly new, so I feel like I must be missing something.
mythz
From its documentation [1] it looks a lot like a parceljs replacement [2], i.e. a zero config bundler which processes and bundles the dependencies in .html pages. So great for simple websites, not for replacing an entire Vite stack.
sampullman
Thanks for the links! I should have researched a little more before replying.
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).
nsonha
> framework specific plugins (like the Vue SFC compiler)?
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.
sampullman
If that's what you prefer, there are plenty of options. I'm happy writing Typescript with no framework (or even plain es6), as long as there isn't UI complexity.
But for a large project, I'll happily trade a compilation step for the tools modern frameworks provide for managing complexity.
msoad
I have not tried Bun yet but the long list of features makes me skeptical that it's all solid and bug-free. I'm wishing to be wrong. I'll give it a spin in a future project.
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.
swiftcoder
> while you're still not 100% Node.js compatible
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?
homebrewer
Do you inspect 100% of the code of each library you use to make sure it does not rely on missing or incompatible functionality?
swiftcoder
I mean, you are either auditing your supply chain or you are not. And if you are not, then minor node incompatibilities are the least of your worries.
bmacho
> I have not tried Bun yet but the long list of features makes me skeptical that it's all solid and bug-free.
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...
re-thc
> From a project management perspective
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.
msoad
This is a very uniformed response IMO. S3 seems very niche compared to Node.js compatibility. Not sure why you're attacking me for saying this?
yoavm
You mentioned Next.js and then Node.js. As for Next.js, it is supported by Bun (https://bun.sh/guides/ecosystem/nextjs). I don't think it's safe to assume that every single Node API is more commonly used than S3, which really is the standard cloud-based object storage API.
elchangri
S3 and niche don't fit in same sentence
nsonha
> a bug where bun add would not respect the spacing and indentation in your package.json. Bun will now preserve the indentation of your package.json, no matter how wacky it is
I find this entry pretty funny. Who even asks for this and what makes they think it's worth writing code for.
yieldcrv
I’ve used it on big existing projects with tons of dependencies and small projects
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
mythz
Couldn't think of a project that was more doomed to fail than a competing alternative to Node.js, but glad that I gave it a shot when I needed to create lots of stand-alone scripts to process text files and SQLite DB updates which I was able to create with TypeScript, bun:sqlite [1] and bun $ Shell [2] working OOB without needing to manage any configuration files or local npm dependencies.
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
joshstrange
I actually used Bun for the first time the other day and it was an amazing experience. All my projects have Webpack or Vite configured to let me write Typescript and once setup they work almost flawlessly but it’s a pain to set it all and not worth it for small scripts.
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.
0xferruccio
I love the direction, especially including s3 and Postgres support natively - it makes a ton of sense for this to exist as an alternative to the “build your own framework” status quo
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)
tmikaeld
Batteries included makes a huge difference, this is why i love that Web APIs (Fetch API, Service Workers, Web Components, and ES6+, WebRTC etc) are now native on both V8 and Webkit runtimes.
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.
chrisandchris
There was a discussion here on HN a while sgo, why browser will not support SQLite 1st hand. Maybe that point applies to Bun too:
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.
lvncelot
Really liking the text-based lockfile. I know there's a way to get diffing locally via a `[diff "lockb"]`, `textconv = bun` git setting, but that's still 1. manual setup, and 2. not really webui friendly.
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?
hamandcheese
Re: bun patch, it would be great if it were possible to fetch remote patches (with a sha specified).
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.
sausagefeet
Can anyone speak to the performance numbers on the Bun page? It represents itself as significantly faster than the existing options, but why is that the case? Is it related to Bun itself? It must be the JavaScript engine they chose right? My understanding is it uses the Safari one rather than V8. Is JSC really that much faster? If so, what are the trade-offs of choosing that over V8 or any other option?
nicoburns
> Is JSC really that much faster
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)
rob74
It's surprisingly hard to find an answer to this (an FAQ on the Bun site would be a good idea?), but I suspect it has to do with reimplementing some stuff (bundler, package manager, test runner etc.) in a compiled language (Zig) rather than using the JS runtime for everything (this is probably also the reason why Bun integrates so many functions into one "kitchen-sink" executable), and using a JS runtime which is faster than V8 at least in some regards.
pansa2
> My understanding is it uses the Safari [JavaScript engine] rather than V8
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.
DanielHB
From their docs it is "written in zig" which implies "all of it is Zig". They don't hide that they use JSC but they don't like to advertise either.
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.
intelVISA
Well in their defense it would hard to get funding for JavaScriptCoreWrapper.sh so it's a useful misunderstanding to curate.
culi
I maybe chose the wrong horse and hopped onto deno early on. Bun's success has really surprised me. It had some really misrepresented benchmarks that were oft-repeated early on that seemed to contribute to it but they've been able to really capitalize on its hype since then. I guess choosing a small up-and-coming language like zig has the added benefit of making that entire community rally behind you
diggan
> I maybe chose the wrong horse and hopped onto deno early on
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...
int_19h
OTOH it's strange to me that they're shipping v1.2, when Zig itself is at v0.13 (and generally considered a moving target).
culi
Zig is following a different versioning philosophy. It's not semver, it's https://0ver.org/
sampullman
A bit ambitious maybe, but I don't necessarily see why breaking changes in Zig would need to be exposed to end users.
Using bun has been a great experience so far. I used to dread setting up typescript/jest/react/webpack for a new project with breaking changes all over the place. With bun, it’s been self contained and painless and it just works for my use. Can’t comment on the 3rd party libraries they are integrating like s3, sql etc but at least it looks like they are focused on most common/asked for ones.
Thanks for the great work and bringing some much needed sanity in the node.js tooling space!