Hacker News Reader

Comment by tmikaeld | Hacker News Reader

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.

View on HN

> Even at that level it's a lot of added code which means slower executable.

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.

All modern build tools have pretty good tree shaking. If you don't use these features they should have basically no impact on your final build

Neither deno nor bun do tree shaking because they can’t make the same assumptions as front end code. They do cache the compiled code though, which makes some difference. But the reason S3 SDK is at least 5X slower than bun, is partly due to code size, since JavaScript always have to parse the code on every run. I worked 3 years on cloudflare workers and scripts even 1MB in size are slow and cpu intensive to run (before using it!). Now, even the most common auth for node with basic features is 20MB of scripting. That put a perspective on things like this.

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.

Well, also there isn't a reliable consensus on what "sqlite" actually is, due to extensions and build flags.

I think the argument in favor of S3 is that there are many object storage services that implement an S3-compatible API. I know its not truly a web standard, but it is also something that a lot of people have standardized around.

> Even at that level it's a lot of added code which means slower executable.

> article literally provides benchmarks, where bun is twice faster than fastest Node.js solution

Reply on news.ycombinator.com