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.
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.
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
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.
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.
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.
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.
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 ;)
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?".
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.
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.
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.
Using bun has been a great experience so far. I used to dread setting up typescript/jest/react/webpack for a new project with breaking changes all over the place. With bun, it’s been self contained and painless and it just works for my use. Can’t comment on the 3rd party libraries they are integrating like s3, sql etc but at least it looks like they are focused on most common/asked for ones.
Thanks for the great work and bringing some much needed sanity in the node.js tooling space!
Lots of good stuff here, but I do wonder if some of the default behaviour is getting a little too magical:
When you use new Response(s3.file(...)), instead of downloading the S3 file to your server and sending it back to the user, Bun redirects the user to the presigned URL for the S3 file.
That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
I respect the area Bun is trying to carve out, but if you follow the creator on Twitter, you'll see the decision making process is very focused on short-term wins/convenience and very light on the deeper implications of the "magic"
I was initially excited about the project, but have no faith in the long term direction given the spurious (and often poor IMO) design decisions. At least as it's publicized on socials.
It would have been fine if they kept it v0.x, but releasing 1.0 should have significantly raised the bar for increasing API surface area
I don't like this design, thought I get why they did it. Personally I think this is very 'side effecty', and it reads like you'd be returning the file contents and not a URL.
Even so, what would bother you about exposing the bucket? It's also a presigned URL so it doesn't have broad access utility.
I'd prefer an API like this where it's explicit:
Response((file(...).getPresignedURL()))
Alternatively, the option to set an env variable or bun config which turns this behaviour on
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.
> 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.
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.
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.
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.
> 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.
> 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.
HTML imports
In Bun 1.2, we've added support for HTML imports. This allows you to replace your entire frontend toolchain with a single import statement.
To get started, pass an HTML import to the static option in Bun.serve:
Couldn't think of a project that was more doomed to fail than a competing alternative to Node.js, but glad that I gave it a shot when I needed to create lots of stand-alone scripts to process text files and SQLite DB updates which I was able to create with TypeScript, bun:sqlite [1] and bun $ Shell [2] working OOB without needing to manage any configuration files or local npm dependencies.
I've since tried it with new JS/TypeScript Projects which also makes use of its built-in Bundler [3] and testing support [4], installing deps is also instant. Having everything work OOB, fast, are real quality of life improvements where Bun has now become my first choice for any new JS project.
I actually used Bun for the first time the other day and it was an amazing experience. All my projects have Webpack or Vite configured to let me write Typescript and once setup they work almost flawlessly but it’s a pain to set it all and not worth it for small scripts.
On the other hand Bun worked right out of the box. I had spent 10-30 minutes futzing around with node-ts or whatever the tool is to run TS “directly” on the CLI and I was dealing with the all the dreaded messages “not a module”, “can’t use import/require”, “ESM/CJS” and trying all the normal fixes (changing package.json module type, changing tsconfig, changing the way import/require) all to get a ~200 line script to run. I switched to Bun as a Hail Mary and it worked wonderfully.
I love the direction, especially including s3 and Postgres support natively - it makes a ton of sense for this to exist as an alternative to the “build your own framework” status quo
This is the standard in every web framework like Rails and Laravel, and the JS ecosystem will really benefit from this. The next steps are migration and schema management and a better out of the box testing story (w/ nice way to setup factories)
From what I can tell, this change was merged and released without a passing build. Indicating that the project’s quality assurance process is little more than lip service. I’m not sure how you would track regressions if your tests are flakey to begin with.
I just tried Bun to make a script to copy files from a service we were moving off of to S3 and it's pretty great.
Instead of having to tinker with my package.json, tsconfig.json, etc. to get everything just right, it works right of the box the way you expected with `bun init`.
Then it's just `bun run index.ts`.
And it's fast!
Node is great but there's just too many options to configure. I appreciate that Bun went ahead and made a bunch of assumptions and pulled commonly used stuff directly into it.
I maybe chose the wrong horse and hopped onto deno early on. Bun's success has really surprised me. It had some really misrepresented benchmarks that were oft-repeated early on that seemed to contribute to it but they've been able to really capitalize on its hype since then. I guess choosing a small up-and-coming language like zig has the added benefit of making that entire community rally behind you
>To work around this, we had to change the assertion logic in some tests to check the name and code, instead of the message. This is also the standard practice for checking error types in Node.js.
Sounds like something they should try upstreaming?
Now they'll need to track all the tests to manually modify/import...
Really liking the text-based lockfile. I know there's a way to get diffing locally via a `[diff "lockb"]`, `textconv = bun` git setting, but that's still 1. manual setup, and 2. not really webui friendly.
Other stuff, like the C interop and psql client sounds amazing as well.
I'm currently only using Bun for smaller sideprojects where I'm also trying to use some of the more out-there features, and it has been a blast so far.
Though the most important question for me (as always with these announcement videos): where can I get a bun plush?
Can anyone speak to the performance numbers on the Bun page? It represents itself as significantly faster than the existing options, but why is that the case? Is it related to Bun itself? It must be the JavaScript engine they chose right? My understanding is it uses the Safari one rather than V8. Is JSC really that much faster? If so, what are the trade-offs of choosing that over V8 or any other option?
These improvements look amazing! I'm always blown away by the performance benchmarks of Bun.
Can anyone speak to how much adoption it's getting professionally? Even anecdotal points are useful. When v1.0 was released I briefly tried testing it out in my employer's monorepo. It unfortunately wasn't a drop-in replacement and we hit compatibility issues/couldn't invest time debugging. While we could have migrated smaller projects to it, we decided not to split our tooling and just stuck with pnpm.
Curious if others have had a different experience!
[+] [-] Cthulhu_|1 year ago|reply
[+] [-] jbergstroem|1 year ago|reply
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.
[+] [-] skwee357|1 year ago|reply
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
[+] [-] shubhamjain|1 year ago|reply
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.
[+] [-] jeswin|1 year ago|reply
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.
[+] [-] supriyo-biswas|1 year ago|reply
[+] [-] jatins|1 year ago|reply
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
[+] [-] h1fra|1 year ago|reply
[+] [-] Aeolun|1 year ago|reply
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|1 year ago|reply
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 ;)
[+] [-] sod|1 year ago|reply
[+] [-] kyriakos|1 year ago|reply
[+] [-] rakatata|1 year ago|reply
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.
[+] [-] ksec|1 year ago|reply
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.
[+] [-] culi|1 year ago|reply
[+] [-] sergiotapia|1 year ago|reply
[+] [-] Karupan|1 year ago|reply
Thanks for the great work and bringing some much needed sanity in the node.js tooling space!
[+] [-] iainmerrick|1 year ago|reply
When you use new Response(s3.file(...)), instead of downloading the S3 file to your server and sending it back to the user, Bun redirects the user to the presigned URL for the S3 file.
That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
[+] [-] adam_arthur|1 year ago|reply
I was initially excited about the project, but have no faith in the long term direction given the spurious (and often poor IMO) design decisions. At least as it's publicized on socials.
It would have been fine if they kept it v0.x, but releasing 1.0 should have significantly raised the bar for increasing API surface area
[+] [-] hombre_fatal|1 year ago|reply
Response(file.stream())
[+] [-] steve_adams_86|1 year ago|reply
Even so, what would bother you about exposing the bucket? It's also a presigned URL so it doesn't have broad access utility.
I'd prefer an API like this where it's explicit:
Alternatively, the option to set an env variable or bun config which turns this behaviour on[+] [-] tmikaeld|1 year ago|reply
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.
[+] [-] jjice|1 year ago|reply
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.
[+] [-] chrisandchris|1 year ago|reply
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.
[+] [-] chipgap98|1 year ago|reply
[+] [-] wiseowise|1 year ago|reply
> article literally provides benchmarks, where bun is twice faster than fastest Node.js solution
[+] [-] hu3|1 year ago|reply
I'm told their dev experience with Bun is out of this world bonkers good because of speed and simplicity.
Dev experience can play a big role long term. If your codebase and/or process sucks, you'll lose good people unless you pay FAANG tier compensation.
[+] [-] msoad|1 year ago|reply
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.
[+] [-] swiftcoder|1 year ago|reply
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?
[+] [-] re-thc|1 year ago|reply
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.
[+] [-] bmacho|1 year ago|reply
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.
[0] : https://news.ycombinator.com/item?id=41720995 [1] : https://github.com/ziglang/zig/issues/16467#issuecomment-164...
[+] [-] drewbitt|1 year ago|reply
[+] [-] nsonha|1 year ago|reply
I find this entry pretty funny. Who even asks for this and what makes they think it's worth writing code for.
[+] [-] yieldcrv|1 year ago|reply
I’m impressed
The dumbest thing I saw was Amazon’s CDK library looking for specific package manager lockfiles and was therefore semi-incompatible with bun
But if you use SST it doesnt matter
[+] [-] Imustaskforhelp|1 year ago|reply
To get started, pass an HTML import to the static option in Bun.serve:
import homepage from "./index.html";
Bun.serve({ static: { "/": homepage, },
});this is amazing and so cool thanks a lot !!
[+] [-] mythz|1 year ago|reply
I've since tried it with new JS/TypeScript Projects which also makes use of its built-in Bundler [3] and testing support [4], installing deps is also instant. Having everything work OOB, fast, are real quality of life improvements where Bun has now become my first choice for any new JS project.
[1] https://bun.sh/docs/runtime/shell
[2] https://bun.sh/docs/api/sqlite
[3] https://bun.sh/docs/bundler
[4] https://bun.sh/docs/cli/test
[+] [-] joshstrange|1 year ago|reply
On the other hand Bun worked right out of the box. I had spent 10-30 minutes futzing around with node-ts or whatever the tool is to run TS “directly” on the CLI and I was dealing with the all the dreaded messages “not a module”, “can’t use import/require”, “ESM/CJS” and trying all the normal fixes (changing package.json module type, changing tsconfig, changing the way import/require) all to get a ~200 line script to run. I switched to Bun as a Hail Mary and it worked wonderfully.
[+] [-] graynk|1 year ago|reply
node --experimental-strip-types index.ts
On non-latest Node tsx package worked great for me (as oppposed to ts-node)
But both of those options just throw away type information (and so does Bun)
[+] [-] 0xferruccio|1 year ago|reply
This is the standard in every web framework like Rails and Laravel, and the JS ecosystem will really benefit from this. The next steps are migration and schema management and a better out of the box testing story (w/ nice way to setup factories)
[+] [-] atoko|1 year ago|reply
[+] [-] martpie|1 year ago|reply
It seems they just drafted a new release to communicate the groups of change from the previous releases.
[+] [-] Jarred|1 year ago|reply
[+] [-] cdmckay|1 year ago|reply
Instead of having to tinker with my package.json, tsconfig.json, etc. to get everything just right, it works right of the box the way you expected with `bun init`.
Then it's just `bun run index.ts`.
And it's fast!
Node is great but there's just too many options to configure. I appreciate that Bun went ahead and made a bunch of assumptions and pulled commonly used stuff directly into it.
[+] [-] culi|1 year ago|reply
[+] [-] voiper1|1 year ago|reply
Sounds like something they should try upstreaming?
Now they'll need to track all the tests to manually modify/import...
[+] [-] lvncelot|1 year ago|reply
Other stuff, like the C interop and psql client sounds amazing as well.
I'm currently only using Bun for smaller sideprojects where I'm also trying to use some of the more out-there features, and it has been a blast so far.
Though the most important question for me (as always with these announcement videos): where can I get a bun plush?
[+] [-] sausagefeet|1 year ago|reply
[+] [-] yard2010|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] crakhamster01|1 year ago|reply
Can anyone speak to how much adoption it's getting professionally? Even anecdotal points are useful. When v1.0 was released I briefly tried testing it out in my employer's monorepo. It unfortunately wasn't a drop-in replacement and we hit compatibility issues/couldn't invest time debugging. While we could have migrated smaller projects to it, we decided not to split our tooling and just stuck with pnpm.
Curious if others have had a different experience!