I find it weird that they bundle s3 and postgres support directly into a runtime instead of having them as libraries. Looking at the documentation for s3, I see
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.
and I get that it’s better to have a native implementation rather than a pure JavaScript one for speed (though I’m skeptic of their 5x claim). But I can’t see this approach scaling. If performance is a concern, then other services you communicate with also need to be fast. In particular Redis/memcached or whatever caching mechanism you prefer, but also ElasticSearch or maybe some Oracle database you need to talk to as well. Should those also be in the runtime? And how do you handle backwards compatibility for those libraries?
I guess this is just a long-winded way of saying “Why aren’t they implementing this as native add-ons and instead force this into the runtime?”. It feels much more modular and sensible to put it outside of the runtime.
My two biggest complaints are mostly to do with the API - one being that s3 is imported from bun, rather than bun/s3 or similar. Python provides a big stdlib, but the modules still have different names. You don’t do from python import DefaultDict, httplib, for example.
The other one is that the file function supports s3 URIs, which is nice from a minimal API perspective, but I also think it’s not ideal to treat s3 the same as local files. s3 has a lot of additional setup - e.g AWS credentials, handling auth errors, etc. So I think it makes sense to logically separate the behaviour for local vs remote files.
I don’t mind new takes on AWS / postgres sdks, though. The SDK is pretty decent compared to some others (e.g Google or Slack), but I think both their AWS and postgress examples there (other than the two issues I mentioned) are pretty nice.
I agree with your sentiment and I am also very confused why I would use the Bun s3 implementation over the whole AWS SDK that I have been using and accustomed to for years now. Sure there could be some performance gains (for just S3) but I don’t see the benefit.
I’ve run into contention on S3 in a Python backend, and it’s really not fun. It’s a very good feature to have this sorted and guaranteed to work fast, it means that Bun can stay competitive with compiled languages for more intensive workloads. To me, this is a production mindset: identify the key components, and optimise them so that they don’t get in your way.
The problem I’ll always have with Bun is that they lied about NodeJS compatibility.
Very common APIs like request.clone() not cloning the body, or gzip not being supported for Web API streams borke things like Clerk auth on the backend.
Their websocket implementation also modified the body data so it broke PCM audio formats.
These things took hours to debug each.
If they had a product they sold, that’d be false advertising for sure. We definitely lost a lot of developer hours to this negligence.
In late 2022, they raised fund from VC with support from Guillermo Rauch (CEO of Vercel) so they’ve some runway. At the time, the founder said they will offer hosting and cloud computing services after the stable release but it seems things have shifted a bit.
Bun’s long term goal is stated:
to be a cohesive, infrastructural toolkit for building apps with JavaScript/TypeScript, including a package manager, transpiler, bundler, script runner, test runner, and more.
So the goal is to capture the JS infra ecosystem then take it from there. I imagine if the performance claims hold, the cost reduction alone will be enough for cloud companies like Vercel to keep investing and promote it further. Is it not pretty much the same with how other open source projects like nodejs are funded?
I find it weird that they bundle s3 and postgres support directly into a runtime instead of having them as libraries. Looking at the documentation for s3, I see
and I get that it’s better to have a native implementation rather than a pure JavaScript one for speed (though I’m skeptic of their 5x claim). But I can’t see this approach scaling. If performance is a concern, then other services you communicate with also need to be fast. In particular Redis/memcached or whatever caching mechanism you prefer, but also ElasticSearch or maybe some Oracle database you need to talk to as well. Should those also be in the runtime? And how do you handle backwards compatibility for those libraries?
I guess this is just a long-winded way of saying “Why aren’t they implementing this as native add-ons and instead force this into the runtime?”. It feels much more modular and sensible to put it outside of the runtime.
Deno is doing the exact same thing so they are likely following suit. This is probably one of the ways Oven intends on monetizing the runtime.
My two biggest complaints are mostly to do with the API - one being that s3 is imported from bun, rather than
bun/s3or similar. Python provides a big stdlib, but the modules still have different names. You don’t dofrom python import DefaultDict, httplib, for example.The other one is that the
filefunction supports s3 URIs, which is nice from a minimal API perspective, but I also think it’s not ideal to treat s3 the same as local files. s3 has a lot of additional setup - e.g AWS credentials, handling auth errors, etc. So I think it makes sense to logically separate the behaviour for local vs remote files.I don’t mind new takes on AWS / postgres sdks, though. The SDK is pretty decent compared to some others (e.g Google or Slack), but I think both their AWS and postgress examples there (other than the two issues I mentioned) are pretty nice.
I agree with your sentiment and I am also very confused why I would use the Bun s3 implementation over the whole AWS SDK that I have been using and accustomed to for years now. Sure there could be some performance gains (for just S3) but I don’t see the benefit.
I’ve run into contention on S3 in a Python backend, and it’s really not fun. It’s a very good feature to have this sorted and guaranteed to work fast, it means that Bun can stay competitive with compiled languages for more intensive workloads. To me, this is a production mindset: identify the key components, and optimise them so that they don’t get in your way.
The problem I’ll always have with Bun is that they lied about NodeJS compatibility.
Very common APIs like request.clone() not cloning the body, or gzip not being supported for Web API streams borke things like Clerk auth on the backend.
Their websocket implementation also modified the body data so it broke PCM audio formats.
These things took hours to debug each.
If they had a product they sold, that’d be false advertising for sure. We definitely lost a lot of developer hours to this negligence.
Here’s a timely reminder that Amazon is not responsible for supporting third-party S3 stuff, so maybe it’s not such a great idea to pretend like it’s some kind of open standard and bake it into a runtime.
Forgive me for going off on a tangent but how do the people behind Bun make money or remain sustainable?
In late 2022, they raised fund from VC with support from Guillermo Rauch (CEO of Vercel) so they’ve some runway. At the time, the founder said they will offer hosting and cloud computing services after the stable release but it seems things have shifted a bit.
Bun’s long term goal is stated:
So the goal is to capture the JS infra ecosystem then take it from there. I imagine if the performance claims hold, the cost reduction alone will be enough for cloud companies like Vercel to keep investing and promote it further. Is it not pretty much the same with how other open source projects like nodejs are funded?
The OpenJS Foundation, which supports nodejs development, is not VC-funded.
I was talking about the second part where cloud companies like Vercel will be sponsoring its development and support the project. Not VC.
The VC funding might be what got them here but it’s old and likely reaching its end.