DO NOT USE BUN (bun install is good dough)
HTML-код
- Опубликовано: 2 июн 2024
- 00:00 Bun is here
00:31 porting to Bun
01:05 log import perf
02:40 MariaDB perf
03:21 reporting perf
03:50 bun install on dev
06:14 macOS disk usage
06:37 bun install on CI
07:19 porting the website
09:30 bun test
12:08 bun --watch
12:54 page load speed
14:32 CI builds
15:55 more testing
16:27 pros and cons of Bun
17:26 me and Bun
Benchmark code: github.com/quick-lint/bun-vs-...
(Analytics benchmarks use production data not present in the repo due to privacy concerns.)
Hardware used for benchmarks:
Linux dev machine: AMD Zen 3 5950X; Linux Mint 21.2; Linux 5.19.0-46-generic
Mac dev machine: Apple MacBook Pro M1 Max (2022)
VPS: Vultr; 1 Intel Haswell vCPU; Ubuntu 20.04; Linux 5.15.0-50-generic
Software used for benchmarks:
Node version v20.6.1
Yarn version 1.22.19
Bun version v1.0.1
Thumbnail artwork by Jennipuff
Bun logo copyright Codeblog Corp
Node.js logo copyright OpenJS Foundation nodejs.dev/en/about/branding/
Yarn logo copyright yarnpkg(?), Creative Commons Attribution 4.0 International (CC BY 4.0) license 
Наука
![Eminem - Houdini [Official Music Video]](http://i.ytimg.com/vi/22tVWwmTie8/mqdefault.jpg)
Man, this right here is an example of quality content. You don't only show results but most importantly HOW you get those results. Testing methodologies are often omitted for simplicity but I believe it reduces content quality by a lot.
I never met this channel and the first 10 seconds made me subscribe.
imagine a RUclips video with _error bars_???!
Jest isnt actually slower than Jasmine, considering how much more features you use ; ]
Jest is a more modern and comprehensive testing framework than Jasmine. Jest includes features like snapshot testing, code coverage analysis, and parallel test execution, which are unavailable in Jasmine.
> Jest includes features like snapshot testing, code coverage analysis, and parallel test execution, which are unavailable in Jasmine.
Even if you use none of those, Jest is slower.
With Jest, you pay a cost for features you do not use.
I loved how he addressed the growing problem of lazy youtubers uploading themselves only reading the marketing announcements of new technologies.
Your first merch could be a shirt: Bun --run doesn't run bun, but bun --bun run runs bun.
This... is just... BRILLIANT
I already have merch: strager.net/booty/
I thought I hadastroke reading this the 1st time. Brilliant lol
Buntime, Funtime :D
How many runs could bun --run run if --run ran bun --bun run?
This is the guy you need in every team. Sometimes, we get excited about new tools until we dug ourselves into a hole.
"Bun run doesn't run bun, but bun --bun run runs bun" is gonna be stuck in my head all day now.
Great video. Appreciate the detailed comparison. Alleviates my Bun FOMO for the time being.
Absolutely incredible video - there's been a lot of hype (and a small amount of skepticism) around bun; but this is the first "proper" comparison I've seen that goes beyond "hello world"
Also loved the little "bun pun counter" at the bottom right
For work related projects, I swapped in node just to see if it was going to be a smooth process. It was not. However, on a home project that doesn't have a client (yet) the server-side bun processing and testing has been phenomenal, imo. Makes me hope Bun continues improving for sure.
Really quality video here, I feel like you are amazing at showing how different frameworks and tools compare in an actual production environment rather than just one that was built simply for the benchmark. This is only Bun 1.0 so there is a good chance a lot of things improve over the next few years, so I’d be interested to see a similar video a few years down the line seeing if bun was able to pull off what it promised outside of its package manager.
Great to see a more balanced perspective. i really like the direction of Bun, especially it's APIs. Will certainly play a bit with it and keep an eye on its hopeful progress
Appreciate the deep dive into this! You do a great job of covering the real issues that would unfortunately only surface in complicated builds.
I would say bun is definitely promising, iterative design can get you far, though sometimes you just need to start over for big optimizations. It definitely needs more polish and battle testing, but I think the direction is good, it's a little overhyped rn.
The concept is good , they literally tried to purge as much js from the code base and replace it with zig without killing the ecosystem and surprisingly it works very well for how new this is. Remember how much of a pain ts was to set up when it was new? In comparison bun is more polished but still has a long way to go.
I agree with everything you say except that I find it to be hyped just the right amount. Hype exposure is relative to what we look at too I suppose.
@@andrewdunbar828 Yeah I see what you mean, I'm personally seeing a bit too much sentiment to rush it into prod because free performance, but that's kinda the blind "is googer" mentality that comes with any new technology I guess
Great video. Specific metrics like this add a lot to the quality, something you're one of the few to do it.
Also, "bun bun run runs bun" is the great piece of alliteration you've produced.
Great video! Really a great job on this - like your perfect hash tag vid, the time flew by while watching this. The bun pun counter was a nice as well! Still the best video on bun to date imo.
Nicely done. I did some testing too and found similar results. I think what made me put bun back in the oven was when I was getting partial results with no errors or warnings. I just happen to notice some data missing, and then ran with node and the data was there. I would've been fine if I had an error thrown, but I don't have time for silent errors. I'll check back in on Bun 2.0.0
This video is a good reminder that as professionals, we can't take marketing at face value and we should conduct rigorous tests and benchmarks to make any real recommendations for new technologies. This video is excellent in demonstrating those values.
Awesome video! Thank you for measuring stuff and not just reading reports made by others!
Would love to see a comparison with deno as well with all of these tests. Or releasing a test suite based on this
I hope no one builds a benchmark suite based on my crappy code! 😅
hmmm suspicious if this comment is not from emcee ; ) @@strager_
@@strager_ XD and when someone says this is crappy and try to implement themself only to end up more crappier...
It works... that's what matters..
Thanks for this video.
I also tried Bun with some of my projects as well and I got a lot of incompatibility errors.
Great to see someone actually go in-depth on the issues!
You're killing it once again. Good job! To my surprise, bun doesn't look so stable after all, I mean `bun --bun run`?
Thank you so much for doing the work for us. 🙂
It appears that JSC (JavaScriptCore) has lackluster performance when it comes to RegEx. Notebly, several RegEx patterns cause JSC to fallback to interpreting and won't be JIT'ed. In addition, JSC appears to be slower for some JIT'ed RegEx as well, likely due to some transformations that V8 is doing that they are not. A bug report has been filed with WebKit about this and hopefully they will address it in time. If your use-case relies heavily on complex RegEx, I would definitely benchmark Node VS Bun to see which one is faster. Simple RegEX appear to be comparable between the two runtimes, but the separation between simple and complex RegEx is not at all clear.
What a great example of how to do an objective comparison of two technologies. It definitely feels like bun has some rough edges and is a little buggy. It has some potential, but I think you've convinced me to wait and look back in a few months.
Thank you for running some real world tests. I did ort of expect something like this since bun hit 1.0 literally a few days ago but i'm holding out and hoping that speeds and compatibility improve in the near future
These were great benchmarks, thanks for sharing!
I'm only at the 2 minutes in the video and I cannot hold myself on already writing a comment. I would like to thank you for been a quality creator, which is something very rare in our days.
Like you did say, most others just made a video after Bun's 1.0 announcement (which is very funny because before that, almost NOBODY big talked about bun but now suddenly, it got so much attention because it hit a milestone? Shows you how these people think...) and they just read the announcement. I did like that you put the effort to make real tests however because I follow Bun for a long time and while they claim to be faster (even "much" faster) than NodeJS, there are indeed a lot of case where they are much, much slower!
Of course, I like the effort behind Bun. These type of projects where people try to replace the "industry standard" tools and make better ones are great, I am making one myself. The problem is that when promises that cannot be met are made and when people lie. In my opinion, Bun should change the whole "faster than NodeJS" to "lighter than NodeJS and an all-in-one tool"! Once Bun matures enough where it's more stable, supports every major API and it beats Node in EVERY test, it can go back to that "faster than NodeJS" motto! Until then, trying to get focus to your project by lying isn't a good idea and it will only backfire at some point!
to be fair prime did many benchmarks with bun before, fireship did a video back in the day about it like a year ago if not mistaken.
however of course official release for something highly anticipated will get a lot of views hence many creators will make videos about it
> before [Bun 1.0], almost NOBODY big talked about bun
Both ThePrimeagen and Theo made videos about Bun many months before 1.0.
ThePrimeagen: ruclips.net/video/qAYFepR4GcE/видео.html
Theo: ruclips.net/video/Rp5yvwX7orE/видео.html
I found Bun flakey/broken in places too, glad to hear I'm not alone in running in to various bugs and issues with it. Looks like you had a lot more patience than I did haha, good work.
That was pretty good. You've clarified some bun weirdness I've experienced myself!
Wow ACTUAL testing?? You've got a subscriber.
Thank you for doing this review.
I’ve been working in Node for a dozen years.
Now I’m deciding whether to advance my stuff to Deno, or to Bun.
Deno it is.
A very informative review!!!
Thank you for adding error bars in a benchmark comparison.
nice, real world benchmark.
it seems Bun's node compatibility has a long way to go.
great info!
that's not the point of bun...
@@MrEnsiferum77
this is actually important or else Bun has to start off its ecosystem from scratch.
@@xavhowahem demo 🥶
@@user-fr2fm3ri3w well, at least better than a lot of helloworlds out there.
that's the whole point of bun, we already have stubborn deno@@MrEnsiferum77
thanks for this video, very useful to see some practicality to the Bun story
This is awesome, thanks for sharing, Strager!
Thank you for all the work, very interesting, hope the bun devs take a look at this.
Oh.. I just asked you a question on X about where/how you learned all of this, and here you are on youtube! I had no idea you were a content creator, but im glad I found you!
hi
Very entertaining presentation, and valuable real-world usage report! Kudos
I agree that using Bun in prod is not a good idea. I haven't noticed much performance gain in actual runtime, but using it for running/testing TypeScript application is a charm, I can absolutely recommend it for local builds as a drop-in Node replacement.
Yeah, I imagine Bun's transpilation is better for TypeScript projects.
I found it useful for having esm in a simple executable ad hoc script. Having imports, commonjs and __dirname available out of the box is really nice. I think NodeJS should learn from that.
Quality content. I much prefer learning about people's real experiences using a tool, rather than the marketing videos and people talking about the marketing videos.
The problem is that, people jumpwagon on bun, not because they like it, but in 2023 JS still is crap about merging all important stuff all together... typescript, decorators, observables and linter... i'm asking for this four every single day... i don't like crap tooling with 20plus dependencies...
Great video. Thank you for this great real dev content.
Really nice testing. I'm still excited for the promise of bun. Bun is IMO what Deno should have always been - focus heavily on node compatibility while coming batteries included to simplify the developer's life. I hope they keep going.
Maybe. The creator of Deno (and Node) said the whole point of Deno was to make what a server-side JS runtime always should have been. That means removing all the bullshit Node has. Adding backwards-compatibility would be antithetical to that vision.
Of course, it turned out that developers don't care about it having better fundamentals from the ground up, and just wanted a better Node.js with TypeScript, fetch, sane module system, test framework, and other conveniences. They don't want to rewrite their projects to be "better". This is what Bun and for the most part newer Node.js does. No code rewriting required 👍🏻
@@MaxCoplan Yeah Deno team totally backtracked on that original idea and went hard into Node/NPM compatibility. They probably realized they won't get much market share without doing that.
@@rand0mtv660The only issue is that they didn't succeed in it. I tried using Deno in a pretty simple CLI application where I also needed to use npm packages and Puppeteer. From the build experience all the way to running it was not a pleasant trip.
I switched to node+esbuild and got it running within minutes...
Amazing real-world benchmarks! Thank you! Finally someone with actual practical use cases on RUclips.
Great work! I'm sure your insights will be quite valuable for the bun developers.
Very informative, thank you for sharing!
The bun video I've been looking for. Thank you very much.
i loved this video & would totally watch a node vs deno one
Excellent breakdown. Thanks for sharing this.
Thanks for the real world analysis. I hope you follow up in a few months.
I love how this video immediately follows the Bun 1.0 release video.
what a great video, just what we needed with all of the bun hype!
I like that it runs my typescript files without transpiling. It does thus better than the esrun package which is what I was using, esrun wasn't showing proper error traces
The burp at the end was the perfect conclusion of this topic!
That's exactly what happens after such a bun feast :)
really cool analysis, thanks strager
This is the video we didn't deserve. Thanks for sharing!
"I'm not going to just read the blog post for you" My exact thought on the first Bun video that RUclips recommended to me. Finally some value add.
Incredible video, thank you
Absolutely nailed all the puns there good work
Also yes I was skeptical of all their claims and now understandably so. But maybe this is something that will improve in the future as they make it more mature. Will be interesting to see if it rises from here
Awesome to see this. I’m surprised they announced this as production ready given. This type of stuff is better to wait till the kinks get worked out on test and fun projects before shipping to prod traffic to it.
Agreed. Let other people take the risks! xD
thank you, great insights, that must be very frustrating, like putting so much effort into migration to bun, just to find out that the app is so much slower when running on bun.
My plan was to make this video, so I accomplished my goal.
I think it's unfair to say that the app was slower with Bun. Some parts were slower and some parts were faster.
Great down to earth video!
thanks @strager . It is worth to evaluate ourselve at this level before we start adopting...
Objective and to the point. Strager never fails to fill up my bun with his knowledge 😫😩😳
I saw a tweet saying the Bun team has the same definition of stable as the Vercel team. That sums up my experience using Bun so far.
Very thorough!! Thanks so much for giving us real world stats
Cant wait for recruiters next year to look for bun jobs with 5 years of experience
Is this a RUclipsr that actually uses a product before spouting off a bunch of hype BS about it? Where am I?
Seriously though, thank you for putting out content about the actual user experience with bun. What they promise is pretty exciting so hopefully they're able to get there eventually but it definitely seems like the "1.0" release was a little premature.
Great work and now I know I don't need to rush into trying a Bun project.
Maybe in a few years Bun will be better, but right now it seems OK and they've mostly cherry picked a bunch of things they've sped up.
Although the packages aren't checked with the network, so you don't actually know if your packages are the latest version.
> Although the packages aren't checked with the network, so you don't actually know if your packages are the latest version.
This is the case with Yarn as well in my application.
I wonder if every exception thrown in bun is slower (and some programs use exceptions for control flow, so you may never see an error as they are in a try/catch). But if bun transpiles every source for require/import compatibility and to digest typescript, it has to postprocess error stacktraces against the source maps to get proper line count reporting.
I imagine source map lookup only happens when you try to print a stacktrace, not when you throw or catch.
I wonder if the bun v1 release was to get more eyes on it (and zig) so that development can move even faster.
So far I'm getting a lot of value from bun for typescript workspaces (since it doesnt need to transpile to run). Previously I'd been using nx, which would piss me off on a regular basis with all the problems it has.
My theory is the vcs funding the company pushed for this release.
One not unimportant aspect is the VC behind Bun, and they likely wanted to see something already.
Yeah, VC influence makes a lot of sense here. Looking at the code/commits/issues that existed before a week ago, a 1.0 release seems completely inconsistent with how unstable the project is. It's the opposite of what rust devs would do.
But in the grand scheme of things, it's probably better for them to release unstable code now. Since releases get people on the hype train, and could lead to contributions by large companies. So by version 4, it'll probably be production-ready.
As someone who worked extensively on JSCore for a couple years, the tracing line issue is something that's been a thing for years. It's just not on the level of V8 based environments.
I've found bun to be extremely fast. But yes I did run into 1 issue where drizzle couldnt intropsect an existing database, luckily thats a one and done kinda thing, so I just used node for that and then bun to actually run the app. It feel liks im using go or something, its just so fast. I love it.
> It feel liks im using go or something, its just so fast. I love it.
interesting. What part of it feels fast?
Bun's command is 3 characters. Node.js's is 4 characters: 33% slower!
@@MaxCoplan basically every command is instant.
@@boot-strapper oh, I see. So it's just placebo affect then.
@@MaxCoplan go use it. It’s faster, in every metric.
Great video! When's the Deno review coming out?
Tomorrow
You're like one of the few devs that i actually trust on youtube. Others feel like youtubers first and developers last or something.
Yeah, I’m just discovering his channel and it seems exactly like that. Although I’d love for him to give a little better explanation regarding his issues. Overall I liked his video
don't trust anybody on the internet.
@@codingsafari It just feels like they used to be developers at some point then switched to youtube and follow every trend but they never really program/build anything anymore.
Their credentials may justify that but it feels a bit weird to me. It just seems like they care more about grabbing any quick views.
Barely anyone takes the time to touch stuff at anything deeper than surface level and spreads bunch of marketing bs like that.
@@zeez7777 As I always say to my viewers, colleagues and pretty much everyone: If you haven't used a specific technology in production, and faced the actual issues and benefits yourself, your opinion is useless.
So yes, you are absolutely right. Content creators live of creating content. Majority don't code, they just watch other videos and replicate the same stuff in different words.
@@zeez7777 "It just seems like they care more about grabbing any quick views." It's a classic "tragedy of the commons" situation: one person starts acting in a selfish way, that's beneficial to them, but harmful to everyone else. Then, more and more people start acting in that selfish way, because short-term benefits are more appealing than long-term ones. Eventually, everyone is acting selfishly, and people wonder what happened, and why everything sucks now. Humans are still stuck at the "monke want many banana" stage, that's what happened. 💀
Excellent video! However the title makes a bit sad. We should maybe not use Bun in production for everything yet, but we SHOULD use bun generally in order to point out issues like some of the ones you mentioned. Oven has already showed they are committed to make improvements in performance in any way they can. I don't doubt that with the proper issues reported they will fix everything they can
> we SHOULD use bun generally in order to point out issues like some of the ones you mentioned
Most people should not use experimental technologies. Most people should be using established technologies to get work done.
Thanks for this!
I've heard that on MacOS copy-file creates a hard-link, so it actually doesn't copy the data on disk, only a pointer that doesn't allow the underlying data to be removed before the last pointer of that type is removed. That seems match what your results show.
A hardlink makes a directory entry which is identical to the original. If you modify the data of one of the files, the other file also changes because they are the *same* file.
A copyfile'd file makes the two files independent, but they share data on disk *if the data remains the same*. If either copy changes, disk usage for that changed part doubles. (This is APFS's copy-on-write feature.)
I also tried bun with an existing medium sized project and had issues as some popular packages use private node apis that don’t exist in bun
I didn't mention this in the video, but my app used an undocumented API: http.Response#writeHeader. It was an easy fix though: call writeHead instead.
What usage of private Node.js APIs did you run into?
@@strager_ the lib jsonpath uses module#_compile from node which was required by react-scrips from create-react-app that one of our 3 year old projects was bootstrapped with
I think that Bun wants to be a "complete" solution to avoid using a lot of different dependencies. I tried to use it on a production project and ran into many issues as well.
this is interesting i would also try pnpm instead of yarn at this point i think that would be pretty close.
Based on other benchmarks I've seen, I doubt pnpm would be 'pretty close' to Bun's performance.
I shall share this video for the rest of the world to see.
I'm enjoying Bun for a NEW project, but switching an already-built application just hasn't felt worth my time for the small gain it would bring (especially compared to the time to switch)
See Bun. See Bun run. See Bun --bun run . Oh , what fun👍
This is one of the best comparison videos. All the other videos never talked about the other side of bun. Thank you so much for this
That burp, was nice.
Great video.🎉
I haven’t seen a case where better-sqlite3 underperforms relative to bun:sqlite. Or where a Node.js test runner outperforms bun test. So I’d like to do some profiling and see what I learn.
Our nodejs polyfills in general do not perform as well as the native implementations. Bun.serve() is a lot faster than node:http
Note; at the time of writing I haven’t finished watching the video yet
Edit: I see the code is linked in the description. I didn’t see it when I wrote this comment
Good to see the creator of bun immedietly working on things and making bun better
If bun is struggling - Jared and team will get it fixed. Very active, very focused on performance and very iterative
I was just about to send you this vid on twitter lol. Nice work
Small update: looks like the code is using lots of RegExp which is being interpreted instead of JIT’d. This is an area where Bun/JSC performs terribly right now. It’s something that needs to get fixed, but it won’t be easy.
@@jarredsumner5983 gl
Really seems like they went as far as possible to optimize for serverless architecture at every point. Minimizing cold start time, cutting package install time, handling simple http connections as fast as possible.
Slow RegEx is reason enough for me not to use it yet.
Maybe you should write a proper parser instead of relying on regex for everything. Remember how Chrome 100 broke 99% of the web because everyone was parsing user-agents with regex?
If JavaScript's manual string processing didn't suck so much, maybe people wouldn't use RegExp as much! xD
When considering a large high-traffic application using serverless, it's very appealing indeed.
I am skeptical about serverless due to the amount of memory Bun allocated in one of the graphs shown. Memory consumption and GC is a big problem for js on servers.
Had to spend a great chunk of time optimizing SSR on my previous job so that it won't run out of memory under load.
strager always has the best, in depth content. A shame about that comic-sans font he uses, I don't get how he does it LOL
Skepticism is greatly needed at this time. I will say this however, how many times have you seen a 1.0 version of a program that works flawlessly? I can't remember when the last time I saw it or even if it did happen. So... let's remain skeptical but also hopeful and see how this turns out.
I really liked the video and ending 17:52 😂. Could you do Deno vs Node similar like this one?
I don't think there's enough interest in Deno vs Node.js. I also think that Deno excels in "soft" areas like editor integration, linting, formatting, benchmarking, etc. which aren't easily condensed into benchmark numbers.
@5:08 Bun accomplishes super fast no-op installs by cacheing some stuff and by skipping the the network check where it ensures with the NPM registry that your current versions are actually the latest. So this is an Apples to oranges comparison, Bun is missing a pretty important feature
> skipping the the network check
Yarn does the same thing, right?
TBH I was just repeating what I heard in this video - ruclips.net/video/1xoy8Q5o8ws/видео.html&ab_channel=Theo-t3%E2%80%A4gg
I'm not 100% sure the ins-and-outs of when and whether cached values are checked against the registry for npm and yarn but it sounds like Bun does less network checks
@@strager_
pushed the like button for the last burp( what a dedication to make funny content ) unironically
For the whole video I was holding that burp in.
Good job 👍
Finaly someone try this on real cases! I dont understand why bun already 1.0 but roadmap is not completed
You gotta ship it at some point. If you wait until it's perfect you'll never release anything.
15:22 I about died hearing this tongue twister! 😂
Bun?
I'm always skeptical when a new product claims to be too good to be true. Good to see that in practice it is more complicated - sure it's better for some things but average or worse for other things. Gotta take everything with a grain of salt or "trust but verify"
To my understanding, when "no work" is done, yarn will check tags like @latest to see if they have updates. Bun does not.
On installations, bun creates symlinks rather than copying the files.
I know pnpm hardlinks node_modules
> yarn will check tags like @latest to see if they have updates.
I don't use @latest though.
> bun creates symlinks rather than copying the files.
No, it doesn't. You can verify this yourself. (You can opt into symlinking with --backend=symlink, and Bun does symlink in some rare cases, but most dependencies will not symlink.)
I don't know where this incorrect information came from, but I see it a lot.
To make this replace Node.js, it requires a lot of effort. How can we create a clean architecture for this? Can we build a good structure with the backend libraries it provides like NestJS? I've tried briefly, but I didn't quite like it.
> How can we create a clean architecture for this?
You mean like what Deno tried?
> Can we build a good structure with the backend libraries it provides like NestJS?
This is such a JavaScripter thing to say.
*Very nice!*
I imagine that the readdir results in bun is returning the results in inode order. My cheap old 3d printer does the same sorting thing when listing files.
Lack of disk usage on OS X is (probably) due to APFS and few others being copy-on-write, so a copy done the right way is free and instant. XFS is not COW but also can do this. Not sure about NTFS and EXT.
Correct. Bun's default install strategy on macOS uses copyfile. People mistook this to mean non-CoW copies.
@@strager_ From my own experience many people don't know what COW, sparse files, xattr (or even hardlinks) are. That's all fine, but when those people make big claims that's.. eh. I saw two videos from same person, first said Bun copies files on MAC, second said that it doesn't, but also said that "on Linux it uses bash feature called symlinks" but "since symlinks are slow on MAC" (it might be true, but rest of the statements make me doubt it) it uses "cloning" which is a "Unix specific" feature that "shouldn't be used often" (I just rewatched the video to double check).