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.
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.
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.
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
"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.
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.
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.
@@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 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
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.
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...
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 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.
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
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
@@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. 💀
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: ua-cam.com/video/qAYFepR4GcE/v-deo.html Theo: ua-cam.com/video/Rp5yvwX7orE/v-deo.html
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.
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.
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.
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.
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
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.
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...
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.
@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
TBH I was just repeating what I heard in this video - ua-cam.com/video/1xoy8Q5o8ws/v-deo.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_
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!
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.
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.
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?
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.
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.
Is this a UA-camr 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.
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.
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)
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
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 will continue using regular node unless I had a very good reason to switch to a different runtime for performance reasons. If it's not broken you shouldn't attempt to fix it. However I do think having more competition within the space of runtimes is good for the ecosystem as a whole, just like how improvements made in yarn were adopted in npm, competition is always a good thing.
> If it's not broken you shouldn't attempt to fix it. This is my mindset as well. 👍 > However I do think having more competition within the space of runtimes is good for the ecosystem as a whole ❤️ You and I are on the same wavelength.
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!!!
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.
> 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.
I'd say relying on undefined behavior (9:30) is not a problem with Bun, it's a user issue For example if in c++ I rely on the order of an `unordered_set`, I'd get burned when I run the same code on different OSes with different implementations
> I'd say relying on undefined behavior (9:30) is not a problem with Bun, it's a user issue Did you mean 9:02? I said "Another minor issue (which is also my fault)". I was blaming myself, not Bun. However, Hyrum's Law suggests that, despite our best intentions, mistakes like this will appear in codebases and will make porting to Bun more difficult. I thought an example of this was worth mentioning in the video.
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
Someone explained that when you install dependencies Bun basically ignores @latest and just serves up the version you have already installed previously. So if you don't clear out the cache it's fast but kind of bad.
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.
What I learned is with package installs, yarn actually does check if it's the correct package, while bun just blindly references it's cache. Hence the time difference.
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"
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
I do wonder where the difference between your report on the speed of the sqlite-features and the one from bun are coming from. Why are theirs so fast while yours are slower than bettersqlite with Node?
I didn't debug that performance difference. Bun's profiler was broken (as I mentioned in the video) and I had a bunch of other things to investigate too.
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.
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 UA-cam 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.
I’m going to use bun and no one can stop me
😂 😅🎉
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.
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
"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.
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.
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 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
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.
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..
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 🥶
@@PanosPitsi well, at least better than a lot of helloworlds out there.
that's the whole point of bun, we already have stubborn deno@@MrEnsiferum77
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...
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 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.
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
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. 💀
Wow ACTUAL testing?? You've got a subscriber.
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: ua-cam.com/video/qAYFepR4GcE/v-deo.html
Theo: ua-cam.com/video/Rp5yvwX7orE/v-deo.html
Appreciate the deep dive into this! You do a great job of covering the real issues that would unfortunately only surface in complicated builds.
Awesome video! Thank you for measuring stuff and not just reading reports made by others!
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.
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.
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.
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
"I'm not going to just read the blog post for you" My exact thought on the first Bun video that UA-cam recommended to me. Finally some value add.
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...
Thank you so much for doing the work for us. 🙂
That was pretty good. You've clarified some bun weirdness I've experienced myself!
Cant wait for recruiters next year to look for bun jobs with 5 years of experience
"Feels like this feature is immature."
No sir, this feature is.... half-baked.
THANK YOU, THANK YOU, I'LL BE HERE ALL WEEK!
Oh, that's a good one!
Thanks for this video.
I also tried Bun with some of my projects as well and I got a lot of incompatibility errors.
You're killing it once again. Good job! To my surprise, bun doesn't look so stable after all, I mean `bun --bun run`?
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.
thanks for this video, very useful to see some practicality to the Bun story
Great video. Thank you for this great real dev content.
@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 - ua-cam.com/video/1xoy8Q5o8ws/v-deo.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_
Thanks for the real world analysis. I hope you follow up in a few months.
The burp at the end was the perfect conclusion of this topic!
That's exactly what happens after such a bun feast :)
0:04 There. Right there. That is why I respect your content. Actual testing, & not lazy reaction content. Thank you 🙏
Amazing real-world benchmarks! Thank you! Finally someone with actual practical use cases on UA-cam.
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
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
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.
This is awesome, thanks for sharing, Strager!
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.
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.
Great to see someone actually go in-depth on the issues!
Great video! When's the Deno review coming out?
Tomorrow
Fake it till you bake it?
Is this a UA-camr 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.
Thank you for adding error bars in a benchmark comparison.
The bun video I've been looking for. Thank you very much.
This is the video we didn't deserve. Thanks for sharing!
See Bun. See Bun run. See Bun --bun run . Oh , what fun👍
what a great video, just what we needed with all of the bun hype!
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.
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)
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
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.
That burp, was nice.
Does Bun 1.1 fix any of these issues?
I will continue using regular node unless I had a very good reason to switch to a different runtime for performance reasons. If it's not broken you shouldn't attempt to fix it. However I do think having more competition within the space of runtimes is good for the ecosystem as a whole, just like how improvements made in yarn were adopted in npm, competition is always a good thing.
> If it's not broken you shouldn't attempt to fix it.
This is my mindset as well. 👍
> However I do think having more competition within the space of runtimes is good for the ecosystem as a whole
❤️ You and I are on the same wavelength.
Best tech content creator, at least in web dev
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
Great down to earth video!
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!!!
These were great benchmarks, thanks for sharing!
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.
Great video, thank you for taking the time to do all this research
Very thorough!! Thanks so much for giving us real world stats
I'd say relying on undefined behavior (9:30) is not a problem with Bun, it's a user issue
For example if in c++ I rely on the order of an `unordered_set`, I'd get burned when I run the same code on different OSes with different implementations
> I'd say relying on undefined behavior (9:30) is not a problem with Bun, it's a user issue
Did you mean 9:02? I said "Another minor issue (which is also my fault)". I was blaming myself, not Bun.
However, Hyrum's Law suggests that, despite our best intentions, mistakes like this will appear in codebases and will make porting to Bun more difficult. I thought an example of this was worth mentioning in the video.
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
WE NEED 3 MORE VERSIONS TO MAKE IT USABLE FOR BIGGER OPTIMIZATIONS.
Someone explained that when you install dependencies Bun basically ignores @latest and just serves up the version you have already installed previously. So if you don't clear out the cache it's fast but kind of bad.
I tried using bun and it didn’t work out at all, it felt like my arms were cut off
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
Objective and to the point. Strager never fails to fill up my bun with his knowledge 😫😩😳
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.
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.
How did you make all those bun puns while keeping a straight face
I am not fun at parties.
i loved this video & would totally watch a node vs deno one
What do you use to display the graphs on video?
The animated graphs were custom built using Motion Canvas: motioncanvas.io/
The memory usage line chart was made with Microsoft Excel.
@@strager_ Thanks! Please do add that to the description of your videos!
@@strager_ Would you mind sharing the code for the graphs at some point?
What I learned is with package installs, yarn actually does check if it's the correct package, while bun just blindly references it's cache. Hence the time difference.
What makes you think that Yarn checks npm?
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"
really cool analysis, thanks strager
someone should send this video to jared
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
15:22 I about died hearing this tongue twister! 😂
Bun?
I do wonder where the difference between your report on the speed of the sqlite-features and the one from bun are coming from. Why are theirs so fast while yours are slower than bettersqlite with Node?
I didn't debug that performance difference. Bun's profiler was broken (as I mentioned in the video) and I had a bunch of other things to investigate too.
Excellent breakdown. Thanks for sharing this.
"in my case bun run doesn't run bun, but bun runs bun" 😂
you got it wrong. bun run doesn't run bun bun bun run runs bun
Finally some sanity in the bun / node discussion. Thank you,
Very informative, thank you for sharing!
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.
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.
thanks @strager . It is worth to evaluate ourselve at this level before we start adopting...