6 ms·

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 runti

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.

sod 2y ago
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 2y ago
  Isn't it possible to write it in Zig as a separate extension? Every mature language I'm aware of supports this AFAICT
  - culi 2y ago
    Tree shaking means it won't bother you if you don't use it
supriyo-biswas 2y ago
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 2y ago
  What’s the monetisation plan
  - timeon 2y ago
    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.
jbergstroem 2y ago
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.
- nsonha 2y ago
  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
- viraptor 2y ago
  > 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 https://nodejs.org/en/blog/release/v23.6.0
  - re-thc 2y ago
    > 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.
  - Shacklz 2y ago
    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.
- homebrewer 2y ago
shubhamjain 2y ago
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 2y ago
  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 2y ago
    > 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
    - animuchan 2y ago
      And it's successful! I've unironically learned about Bun on YouTube, and now am a happy user. :) A set of "blessed" known good packages would be wonderful to have in any language, I wonder why it's not a thing.
      - Raed667 2y ago
        I'm wondering what made you switch ? I find the ubiquity of node very comforting, maybe I'm not seeing the argument that will convert me over ?
Aeolun 2y ago
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.
flohofwoe 2y ago
The interesting question is: Where do you draw the line? Should a HTTP server/client be in the stdlib? File access? String templating? And why not a window system, 3D API and UI wrapper? IMHO a stdlib should mainly provide standardized interface types, but not necessarily the implementations behind those interfaces. But that's probably not a very popular opinion since it falls between the two existing options of having a very bare bones and a batteries-included stdlib ;)
jeswin 2y ago
> 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 2y ago
  > 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....
- azemetre 2y ago
  Just wait until they give preference to services that their VC benefactors are also supporting.
kyriakos 2y ago
it is a very bad idea. you start your project using the built in client libs, you are locked in to bun as js runtime. if the license changes you are stuck.
- SwiftyBug 2y ago
  Not only that, but when the new hot JS runtime inevitably drops, it's going to be a pain to move to that.
  - deleted 2y ago
    [deleted]
  - culi 2y ago
    What "new hot JS runtimes" are you talking about? Node has been pretty stable for over a decade and a half. This is the first time that anything is even challenging that place. It just so happens that both Bun and Deno efforts started around the same time and now have to compete with each other I think any competent company would be savvy enough to avoid lock in for a technology with adoption this low. I don't think that's what these features are aiming for. I think they're aiming for the young dev starting side projects that wants to get up and running quick. Or imagine teaching a bootcamp class and you want a tool that will do some magic for you so you can focus on explaining other complex aspects of web development
    - 8n4vidtmkvmk 2y ago
      You don't think they're trying to lock us in? What's their big monetization plan then? I think they want us to drink the Kool aid. I don't have a problem with it though because I'm small enough that I can still refactor the world in a few days if I really need to.
  - wiseowise 2y ago
    [dead]
skwee357 2y ago
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
- 8n4vidtmkvmk 2y ago
  I think that's the plan too. But I'm still not fussed about it. At the end of the day, it's still a great tool for getting stuff done and one less decision I have to make. Also.. I don't quite know how they're going to lock me in unless they mess with the license. I can deploy my own bun server anywhere, no? I'd be stuck on bun I guess but still not paying anything.
ksec 2y ago
>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.
rakatata 2y ago
s3 is pretty much a de-facto standard, just like json like or not. Postgres also makes sense, it is the most widespread and community-liked db. What is the point of "optional libraries" tbh? It was a PITA in PHP back in the days and very inconvenient, prob most devs would prefer this way. I feel like HN is on cognitive dissonance, they complain JS projects having too many dependencies and they also complain now when things are more integrated into the runtime because it increases vendor-lock and few extra megabytes (actually kilobytes according to the devs) to the binaries :/. Lastly, big companies also prefer less dependencies, it is not just devs.
- chearon 2y ago
  It probably looks very wrong to people who still think lots of "modularity" and small packages is a good thing. I'm all for it, and lots of Bun APIs are purely practical. Bun.stringWidth, for example, exposes code Bun already has internally. Nodejs probably has the same thing, but instead of us being able to use it, it gets reimplemented in 10 different versions in node_modules. How is that better? I doubt the Bun team will have to change the S3 code very much over the years. The test runner, bundler, Postgres client, sure, I can see those being harder to maintain. But I'm also tired of everyone assuming everything needs to change all of the time. DX aside, my team is still on Webpack and we've only needed one new feature from it in the last ~5 years. Why can't Bun's bundler reach maturity and only receive a few updates?
  - pfg_ 2y ago
    Node does have the same thing, and you can access it with `--expose-internals` from `const { getStringWidth } = require("internal/util/inspect");`. They don't expose it for some reason.
  - 8n4vidtmkvmk 2y ago
    I'm also still using webpack. Not sure why the community abandoned it. Haven't had any issues. Everything seems to use babel under the hood anyway and they all have their little wrappers over top.
- Ygg2 2y ago
sergiotapia 2y ago
that's old school javascript mentality. new school is bake it all in and let people get to work on the interesting bits.
h1fra 2y ago
I'm sure in the short term people will be happy, but maintaining that in the long run is a footgun. I can't see a team big enough to achieve that correctly, especially the bug confusion (e.g: is it bun or the 3rd party issue) that will creep on the main repo.
jatins 2y ago
I think it makes it easy to provide paid hosted services later if needed. Hypothetical example: S3 client built in, enable a flag and now get a dashboard seeing analytics around file downloads, download latencies etc Just pure hypothesis on my end given they have to make money somehow at some point
culi 2y ago
I don't like it either but in practice it doesn't really matter. Tree-shaking means those unused features won't affect your project
- 8n4vidtmkvmk 2y ago
  Except that you can't shake built-ins. It's in the bun binary.
  - 7bit 2y ago
    So? IT wont affect performance. Dont call the library and ITS egfectively unused Code in the binary.
    - 8n4vidtmkvmk 2y ago
      I'm not the one complaining. I'm just saying this has nothing to do with tree-shaking.

sod 2y ago

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 2y ago
Isn't it possible to write it in Zig as a separate extension? Every mature language I'm aware of supports this AFAICT
- culi 2y ago
  Tree shaking means it won't bother you if you don't use it

supriyo-biswas 2y ago

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 2y ago
What’s the monetisation plan
- timeon 2y ago
  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.

jbergstroem 2y ago

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.

nsonha 2y ago
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
viraptor 2y ago
> 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 https://nodejs.org/en/blog/release/v23.6.0
- re-thc 2y ago
  > 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.
- Shacklz 2y ago
  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.
homebrewer 2y ago

shubhamjain 2y ago

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 2y ago
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 2y ago
  > 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
  - animuchan 2y ago
    And it's successful! I've unironically learned about Bun on YouTube, and now am a happy user. :) A set of "blessed" known good packages would be wonderful to have in any language, I wonder why it's not a thing.
    - Raed667 2y ago
      I'm wondering what made you switch ? I find the ubiquity of node very comforting, maybe I'm not seeing the argument that will convert me over ?

Aeolun 2y ago

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.

flohofwoe 2y ago

The interesting question is: Where do you draw the line? Should a HTTP server/client be in the stdlib? File access? String templating? And why not a window system, 3D API and UI wrapper? IMHO a stdlib should mainly provide standardized interface types, but not necessarily the implementations behind those interfaces. But that's probably not a very popular opinion since it falls between the two existing options of having a very bare bones and a batteries-included stdlib ;)

jeswin 2y ago

> 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 2y ago
> 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....
azemetre 2y ago
Just wait until they give preference to services that their VC benefactors are also supporting.

kyriakos 2y ago

it is a very bad idea. you start your project using the built in client libs, you are locked in to bun as js runtime. if the license changes you are stuck.

SwiftyBug 2y ago
Not only that, but when the new hot JS runtime inevitably drops, it's going to be a pain to move to that.
- deleted 2y ago
  [deleted]
- culi 2y ago
  What "new hot JS runtimes" are you talking about? Node has been pretty stable for over a decade and a half. This is the first time that anything is even challenging that place. It just so happens that both Bun and Deno efforts started around the same time and now have to compete with each other I think any competent company would be savvy enough to avoid lock in for a technology with adoption this low. I don't think that's what these features are aiming for. I think they're aiming for the young dev starting side projects that wants to get up and running quick. Or imagine teaching a bootcamp class and you want a tool that will do some magic for you so you can focus on explaining other complex aspects of web development
  - 8n4vidtmkvmk 2y ago
    You don't think they're trying to lock us in? What's their big monetization plan then? I think they want us to drink the Kool aid. I don't have a problem with it though because I'm small enough that I can still refactor the world in a few days if I really need to.
- wiseowise 2y ago
  [dead]

skwee357 2y ago

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

8n4vidtmkvmk 2y ago
I think that's the plan too. But I'm still not fussed about it. At the end of the day, it's still a great tool for getting stuff done and one less decision I have to make. Also.. I don't quite know how they're going to lock me in unless they mess with the license. I can deploy my own bun server anywhere, no? I'd be stuck on bun I guess but still not paying anything.

ksec 2y ago

>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.

rakatata 2y ago

s3 is pretty much a de-facto standard, just like json like or not. Postgres also makes sense, it is the most widespread and community-liked db. What is the point of "optional libraries" tbh? It was a PITA in PHP back in the days and very inconvenient, prob most devs would prefer this way. I feel like HN is on cognitive dissonance, they complain JS projects having too many dependencies and they also complain now when things are more integrated into the runtime because it increases vendor-lock and few extra megabytes (actually kilobytes according to the devs) to the binaries :/. Lastly, big companies also prefer less dependencies, it is not just devs.

chearon 2y ago
It probably looks very wrong to people who still think lots of "modularity" and small packages is a good thing. I'm all for it, and lots of Bun APIs are purely practical. Bun.stringWidth, for example, exposes code Bun already has internally. Nodejs probably has the same thing, but instead of us being able to use it, it gets reimplemented in 10 different versions in node_modules. How is that better? I doubt the Bun team will have to change the S3 code very much over the years. The test runner, bundler, Postgres client, sure, I can see those being harder to maintain. But I'm also tired of everyone assuming everything needs to change all of the time. DX aside, my team is still on Webpack and we've only needed one new feature from it in the last ~5 years. Why can't Bun's bundler reach maturity and only receive a few updates?
- pfg_ 2y ago
  Node does have the same thing, and you can access it with `--expose-internals` from `const { getStringWidth } = require("internal/util/inspect");`. They don't expose it for some reason.
- 8n4vidtmkvmk 2y ago
  I'm also still using webpack. Not sure why the community abandoned it. Haven't had any issues. Everything seems to use babel under the hood anyway and they all have their little wrappers over top.
Ygg2 2y ago

sergiotapia 2y ago

that's old school javascript mentality. new school is bake it all in and let people get to work on the interesting bits.

h1fra 2y ago

I'm sure in the short term people will be happy, but maintaining that in the long run is a footgun. I can't see a team big enough to achieve that correctly, especially the bug confusion (e.g: is it bun or the 3rd party issue) that will creep on the main repo.

jatins 2y ago

I think it makes it easy to provide paid hosted services later if needed. Hypothetical example: S3 client built in, enable a flag and now get a dashboard seeing analytics around file downloads, download latencies etc Just pure hypothesis on my end given they have to make money somehow at some point

culi 2y ago

I don't like it either but in practice it doesn't really matter. Tree-shaking means those unused features won't affect your project

8n4vidtmkvmk 2y ago
Except that you can't shake built-ins. It's in the bun binary.
- 7bit 2y ago
  So? IT wont affect performance. Dont call the library and ITS egfectively unused Code in the binary.
  - 8n4vidtmkvmk 2y ago
    I'm not the one complaining. I'm just saying this has nothing to do with tree-shaking.