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.
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?
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.
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.
> 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.
In the early days of the project it was segfaulting during performance tests. That was a pretty hair-raising bit of information for me. Deno it is.
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.
> 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.
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.