11 ms·

I work on Bun. Happy to answer any questions.

by Jarred 2y ago

Y-bar 2y ago
Are there plans for a stripped-down version without S3 and SQL and things like that for those like us who just want a fast runtime to build our frontend resources to static files?
- Jarred 2y ago
  No plans to do that. 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 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.
  - ksec 2y ago
    Thank You Jarred. I seriously dont understand why there is such a huge resistance in including those. Especially when they are faster and more memory efficient.
    - diggan 2y ago
      > why there is such a huge resistance in including those 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.
    - oldpersonintx 2y ago
      [dead]
  - Y-bar 2y ago
    Not worried about size on disk. That said, it's not just runtime overhead I am worried about, it is a handful of smaller risks that compound: Those include security risks, bugs in one section affecting something else, scope creep affecting time-to-fix-bugs, not everything is lazy-loaded so it will affect performance. 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.
    - oldpersonintx 2y ago
      [dead]
Etheryte 2y ago
I see Bun pop up every now and then and it looks amazing. How is the development funded? With projects such as Node, I don't have to worry about it disappearing from underneath my feet, with Bun I'm not so sure.
ibejoeb 2y ago
I didn't think this would be quite so contentious. It's been great for me. I manage very distributed teams across multiple time zones, multiple language barriers, and heterogeneous platforms. It's difficult. Bun makes it easier because the features in the distribution are virtually guaranteed to work together and obviate the tooling version hell. I have fewer 1:1 setup meetings. I haven't had cross-platform issues. Finally, the speed is actually important on lower-tier hardware. 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?
CrimsonRain 2y ago
Some people make it a living out of complex interactions of all tools and make life hell for everyone. Don't listen to them. 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
gr4vityWall 2y ago
thanks for the batteries-included runtime. I really appreciate that aspect. I really don't want to keep glueing libraries together more than neccessary :)

I work on Bun. Happy to answer any questions.

by Jarred 2y ago

I work on Bun. Happy to answer any questions.

Are there plans for a stripped-down version without S3 and SQL and things like that for those like us who just want a fast runtime to build our frontend resources to static files?

Jarred 2y ago
No plans to do that. 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 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.
- ksec 2y ago
  Thank You Jarred. I seriously dont understand why there is such a huge resistance in including those. Especially when they are faster and more memory efficient.
  - diggan 2y ago
    > why there is such a huge resistance in including those 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.
  - oldpersonintx 2y ago
    [dead]
- Y-bar 2y ago
  Not worried about size on disk. That said, it's not just runtime overhead I am worried about, it is a handful of smaller risks that compound: Those include security risks, bugs in one section affecting something else, scope creep affecting time-to-fix-bugs, not everything is lazy-loaded so it will affect performance. 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.
  - oldpersonintx 2y ago
    [dead]

Etheryte 2y ago

I see Bun pop up every now and then and it looks amazing. How is the development funded? With projects such as Node, I don't have to worry about it disappearing from underneath my feet, with Bun I'm not so sure.

ibejoeb 2y ago

I didn't think this would be quite so contentious. It's been great for me. I manage very distributed teams across multiple time zones, multiple language barriers, and heterogeneous platforms. It's difficult. Bun makes it easier because the features in the distribution are virtually guaranteed to work together and obviate the tooling version hell. I have fewer 1:1 setup meetings. I haven't had cross-platform issues. Finally, the speed is actually important on lower-tier hardware. 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?

CrimsonRain 2y ago

Some people make it a living out of complex interactions of all tools and make life hell for everyone. Don't listen to them. 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

gr4vityWall 2y ago

thanks for the batteries-included runtime. I really appreciate that aspect. I really don't want to keep glueing libraries together more than neccessary :)