If you're worried about disk space on Mac OS you could run a script that deletes node_modules for projects you've not used in a while. When Bun is so much faster it's not a big deal to reinstall that project you didn't work on for a week anyway.
@@ricoaw500I agree, definitely hold out on it for now, play around with it, but don't transitoin your entire codebase just yet imo. Wait until the product is more stable, because there WILL be major changes and items being deprecated in future releases (meaning you have to remove and change all of your codebase again).
For my personal projects I will go with 1.0 But with team based or my company related projects I would prefer 2+ or 3+ version with more than sizeable community to even consider it.
Actually, bun shouldn’t use more disk space than pnpm on macOS. On APFS, clonefile is “copy-on-write” but otherwise acts like link. As long as you don’t modify node_modules content, it’s same disk usage as pnpm.
1000%. I've spent wayyy too much time tweaking tsconfigs and package jsons trying to get modules to work the way I want them to. Having a "it just works" solution is a huge benefit.
yea, i was saying back then that node.js should added it like this. but "noo we will never be able to drop require then", for what i say the Date object is foobar too, the fix is add new syntax, so why can't we do it for import too.
@@wliaputs that's simply because ES standard vs Node Standard, the right question to be asked is, why the hell module is introduce very late in the language
I agree. Additionally, the fact that everything is splintered in first place for very little in terms of real world benefits is atrocious. Even if there was a benefit of sorts, there is no real reason why I shouldn't be allowed to just use both module types, at least on the backend. There is no benefit to treeshaking on the server unless you have a million dead packages in your node_modules. However, if you have that, you are probably doing something wrong or have implimented a build step to elminate all that dead code, in which case, how you import still means nothing.
The cached installation wth Bun was so fast that I perceived is as an exception was thrown, my experience has been like: "If the logging finishes too fast it's because something went wrong"
Bun even can compile to an single executable (+ you can embed files into it which is insane). This is going to improve my deployment to customer servers so much
Where is this ? I see in build you can build to a bun target which optimizes a build but i don't think it's like hermes that compiles java-script statically.
@@shadowangel-ou6bg you are correct it doesn't work like hermes. It packages the Buntime and JavaScript source files in the binary which is then run by Bun when it is executed
Bun looks so good, the moment it's a bit more stable for Windows I'm moving over to it. While the speed improvements are nice, the biggest thing for me is being able to just write Typescript and have it work without having to fight with configs. I'm hoping after their core is more stable they'll also take a look into improving the linting world of Javascript
What an eye opener how much CPU time we waste all the time. I chuckled when you said "it's sad to see", no, ITS AWESOME, it was 24x faster than the fastest solution we had so far :D What a time to be alive
8:45 isn't macos' `clonefile` behave like Linux btrfs `cp --reflink` ? So it doesn't really takes a space thanks to CoW (unless you're changing one of the copies)
I think so, from what a quick search into the subject is yielding, so long as the drive is using APFS, since HFS does not support CoW, but APFS does, so any more recent mac should get the space savings as well.
Man!! That last part amazed me 😮 . Hopefully deployment tools start supporting Bun, that’s usually one of the main blockers for organizations that have a lot of restrictions in their tools and tech stack
8:10 Under "Installation strategies": you can use the --backend flag to specify how to "copy" into node_modules, and force hardlinks even on macOS. But clonefile is copy-on-write, so it isn't really needed.
True, clonefile copies only the metadata. "The cloned file (dst) shares its data blocks with the (src) file but has its own copy of attributes, extended attributes and ACL's which are identical to those of the named file" I love COW filesystems. I wonder if Bun does something similar in Btrfs.
I've tried bun on some projects a while ago and it was missing a lot of stuff that I needed. Nowadays it seems it got everything I should need, so I'm thinking of giving it a try again.
It's amazing, Bun provides the cool features of JS ecosystem in a single tool. I really urious how they can make these features in a very short time compared to other tools that took many years to be matured.
It's nice to see a new project with such a huge scope like bun, that proves that things can be simple yet crazy fast. Glad to see so many improvements in the JS ecosystem!
I was quite sceptical of another JS runtime, after not getting much benefit from Deno. But run/build/install times with Bun blew my mind, especially with typescript.
I think it'd be cool to see a video on benchmarks. I see a lot of back and forth about this stuff: how useful they are, how they should be interpreted, what makes for a good benchmark, etc.
Its soo fast and nice. The file api is also very nice to use. I upgraded a websocket server yestday to use bun. There was one incompatible dependency syncfile read but I could actually remove this dependency because bun has the build in prompt function which is very nice. I could throw away a lot of code actually and it starts up like 4 times faster. Great!
This looks really interesting, some of the features would make it a node killer for beginners too because of all the frictions and headbanging stuff that makes the developer experience for those users really painful, if it weren't for the Windows thing which probably many beginners are using.
Important note, bun on windows wont be as performant as it will get in the future as jarred decided he doesnt have enough time before releasing 1.0 to understand how to write fast I/O windows code, so they for now use libuv (what nodejs uses for the I/O)
But Bun allows you to just remove your node_modules and install them again in a fraction of the second once you get back to the project to save on disk space :)
Bun is showing us what javascript could be if every API is implemented natively But at the end of the day, normal js code will still be slower, it's just not slow enough to ditch it
Killer feature is the easy way you can write the hard stuff in zig, and import it as an esmodule to use in a scripting language. Has the potential to overtake python in machine learning. Faster and safer than Rust, with a much better dx
@@davidt01 yeah well that’s potentially a very long conversation that can go sideways quickly. If rust’s concept of safety works for you, then go for it. There are alternative opinions though.
@@davidt01 while it may have manual memory management, it has a lot of in-code ways to help you making it safe, and the compiler alerts if there's a memory leak.
Back in the day we had a project that could reload once for 2.5 minutes. Now people consider using something that instead of 6 seconds installs something in 1 second.
Elephant in the room: Electron. Think of how much you are losing by leaving that behind. If you care about using your existing codebase as a feature complete desktop app, it's a dealbreaker. I don't see any path forward for this either :/
I'd definitely switch to Bun for my full-stack applications when they support Solid-Start. As of now, Bun can initialize a Solid-Start project but cannot run it. Node.js runs under the hood, even when I type `bun run dev` command.
I've run into similar issues with `bun create preact`. This is the same sort of issue I've always run into getting Bun to work on projects since it was first announced. Some key step is just outright missing or incompatible, and the workaround is to tear apart the `npm install` or other such process to track it down and "fix" it. This is just to init a toy project. It's really disappointing. It all sounds great if you're building without a template from scratch (maybe) or if Bun-specific templates are created in the future, but I figured the whole point was to not have to get "Bun-specific" with everything.
I honestly do not care that much about the performance. Node is maybe slow compared to bun but it's fast enough for most server side apps. But the Tooling, OH THE TOOLING. This part got me so excited. The number of hours I've spent in my career setting up parsers, compilers, bundlers, dealing with commonJS/esModules, and then fix it when they break due to some weird dependency. This whole concept of not needing to download 37 modules before I even write a single line, just for the tooling, is soooo freaking compelling.
The bun library is nice, but it has analytics active by default, which means it spies on you. Additionally, it is not compatible with NestJS, despite claims to the contrary. I wouldn't trust using it in a project for anything more than running files; it's not suitable for a real project. Bun is also backed by Y Combinator, which creates a potential conflict of interest with Theo.
As I see your video I have a feeling that everything Bun just solves now out-of-the-box should have worked as is before. I'm just wondering why the whole previously existing ecosystem is so overcomplicated...? It's so funny when you stopped for a moment on the fact that Bun can combine requires and imports in the same file and... wow...! Incredible :)
Real world project benchmark test results after migrating to bun:: Node.Js Total: 97.5701 secs Slowest: 0.3324 secs Fastest: 0.0326 secs Average: 0.0488 secs Requests/sec: 1024.9041 Total data: 1.08 GiB Size/request: 11.29 KiB Size/sec: 11.30 MiB -------------------------------------------------------------------------------- Bun Total: 77.8154 secs Slowest: 0.2495 secs Fastest: 0.0261 secs Average: 0.0389 secs Requests/sec: 1285.0923 Total data: 1.08 GiB Size/request: 11.29 KiB Size/sec: 14.16 MiB -------------------------------------------------------------------------------- Elysia This is a complex application with all kinds of validations and db calls. The migration took around 5 mins but the results were good enough. Keep in mind this is an express application and I'm planning to migrate to Elysia soon.
Some months ago, Jack Herrington tried Bun against Deno and Node, and he faced a lot of segfaults with Bun, besides some other weird behaviors. Hope they fixed those things by now.
Someone said "File cloning on mac OS is essentially like hard linking with copy-on-write. The one downside is that the filesystem doesn't support this for folders." Is this true? If yes, then you could switch to bun in macOS and not worry about disk space usage. Maybe you could test it out.
Disk space usage is also as much an important concern as performance. I think it's a little blindsided to always prioritize performance no matter what. Balance is key, so the question is: Why didn't they give a global option in macOS to do hardlinking instead of cloning files? (If a developer like you doesn't want cloned files all over your disk, and is willing to accept the lower performance, why not?) Also, can you just hardlink yourself later? Will it work?
ive been doing this now for about 6 years, and in the js, go, and rust world. i can't believe how many things are in js. i started w/ js so i thought this was normal but it is true some package is released like every month lol. this looks great but how do we know this will be around in 5 years
I would like to see if you can adopt just parts of Bun not the whole thing. For example, would it be viable to use just the built-in test runner to write tests in an existing Node based project? Great video btw
Can you share link to the project you tested install speed on? I’d like to test it with yarn 4 in pnp mode with global cache (which I guess you didn’t use in the comparison) as it’s cached instal is super fast
If you're worried about disk space on Mac OS you could run a script that deletes node_modules for projects you've not used in a while. When Bun is so much faster it's not a big deal to reinstall that project you didn't work on for a week anyway.
This is lowkey genius
🐐
There is a project for that. It's npkill
@@DatNguyen-vj1rolet's rename it to bunkill
Truly a missed opportunity not calling it npfree
I was ignoring Bun, but after this release it actually looks pretty impressive. They may have a new convert.
isn't normal to ignoring under 1.0 product?
@@ricoaw500I agree, definitely hold out on it for now, play around with it, but don't transitoin your entire codebase just yet imo. Wait until the product is more stable, because there WILL be major changes and items being deprecated in future releases (meaning you have to remove and change all of your codebase again).
For my personal projects I will go with 1.0
But with team based or my company related projects I would prefer 2+ or 3+ version with more than sizeable community to even consider it.
@chyldstudios
bro can you guide me in my career
All the performance benefits are great, but if it frees us from esm/cjs hell, that could be the most compelling feature.
This is one of those videos that come once in a thousand years where I agree with Theo
aside from tailwind yes
Mainly because Theo won't be on TH-cam for a Thousand years.
@@trappedcat3615 💋🐴
@@trappedcat3615 Yes he will. Ever heard of immortal.js?
Lol I disagree with him in this one (and many more), benchmarking proves nothing since it has nothing to do with real world apps
Actually, bun shouldn’t use more disk space than pnpm on macOS. On APFS, clonefile is “copy-on-write” but otherwise acts like link. As long as you don’t modify node_modules content, it’s same disk usage as pnpm.
The ability to run both cjs and esm at the same time is a major selling point to me. In big ecosystems, this can be surprisingly painful.
1000%. I've spent wayyy too much time tweaking tsconfigs and package jsons trying to get modules to work the way I want them to. Having a "it just works" solution is a huge benefit.
yea man, why did they make import incompatible with require 😢
yea, i was saying back then that node.js should added it like this. but "noo we will never be able to drop require then", for what i say the Date object is foobar too, the fix is add new syntax, so why can't we do it for import too.
@@wliaputs that's simply because ES standard vs Node Standard, the right question to be asked is, why the hell module is introduce very late in the language
I agree. Additionally, the fact that everything is splintered in first place for very little in terms of real world benefits is atrocious. Even if there was a benefit of sorts, there is no real reason why I shouldn't be allowed to just use both module types, at least on the backend. There is no benefit to treeshaking on the server unless you have a million dead packages in your node_modules. However, if you have that, you are probably doing something wrong or have implimented a build step to elminate all that dead code, in which case, how you import still means nothing.
The cached installation wth Bun was so fast that I perceived is as an exception was thrown, my experience has been like: "If the logging finishes too fast it's because something went wrong"
I have replaced Pnpm with Bun completely in the last few months and it completely transformed how I develop.
Let's go Ziggggggg !
Love seeing this focus on performance and usability.
Bun even can compile to an single executable (+ you can embed files into it which is insane). This is going to improve my deployment to customer servers so much
Is this in their docs. Im trying to build something like pocketbase for fun
Where is this ? I see in build you can build to a bun target which optimizes a build but i don't think it's like hermes that compiles java-script statically.
@@shadowangel-ou6bg you are correct it doesn't work like hermes. It packages the Buntime and JavaScript source files in the binary which is then run by Bun when it is executed
I bought into bun wholesale from the beginning, and following its progress has been amazing. My workflow has gotten so much faster.
Bun looks so good, the moment it's a bit more stable for Windows I'm moving over to it. While the speed improvements are nice, the biggest thing for me is being able to just write Typescript and have it work without having to fight with configs.
I'm hoping after their core is more stable they'll also take a look into improving the linting world of Javascript
It feels like having it on WSL 2 is going to be faster than the alternatives
You done much on WSL2 yet? I've seen things be faster there than windows.
Oh yeah, linting out of the box would be great
why not just use WSL?
To be fair, Deno has supported this for quite a while now.
What an eye opener how much CPU time we waste all the time.
I chuckled when you said "it's sad to see", no, ITS AWESOME, it was 24x faster than the fastest solution we had so far :D What a time to be alive
Release of the year, great work by the Bun team.
I love that Bun was built with Zig
8:45 isn't macos' `clonefile` behave like Linux btrfs `cp --reflink` ? So it doesn't really takes a space thanks to CoW (unless you're changing one of the copies)
I think so, from what a quick search into the subject is yielding, so long as the drive is using APFS, since HFS does not support CoW, but APFS does, so any more recent mac should get the space savings as well.
Finally some real innovation in this field. Super hyped for Bun.
exactly. this was missing for ages!
Man!! That last part amazed me 😮 . Hopefully deployment tools start supporting Bun, that’s usually one of the main blockers for organizations that have a lot of restrictions in their tools and tech stack
8:10 Under "Installation strategies": you can use the --backend flag to specify how to "copy" into node_modules, and force hardlinks even on macOS. But clonefile is copy-on-write, so it isn't really needed.
this is nice to know
True, clonefile copies only the metadata.
"The cloned file (dst) shares its data blocks with the (src) file but has its own copy of attributes, extended attributes and ACL's which are identical to those of the named file"
I love COW filesystems. I wonder if Bun does something similar in Btrfs.
I've tried bun on some projects a while ago and it was missing a lot of stuff that I needed. Nowadays it seems it got everything I should need, so I'm thinking of giving it a try again.
Employers already asking for 3 years experience in bun.
Psssh 3 is for entry level devs. 8 for seniors!
Bun - "JavaScript so fast it's written in Zig"
I've followed you for at least the last two years!
You've become so mature, and I'm glad to say I respect you a lot for it!
It's amazing, Bun provides the cool features of JS ecosystem in a single tool. I really urious how they can make these features in a very short time compared to other tools that took many years to be matured.
Bun's speeds are just absolutely insane. That too in practical usecases.
Theo: justifies not using bun in order to save disk space
Als Theo: I just can justify not using it
import and require works, wtf. I am sold. I am a bunny now.
It's nice to see a new project with such a huge scope like bun, that proves that things can be simple yet crazy fast. Glad to see so many improvements in the JS ecosystem!
Sounds like bun has been baking to perfection since the last time I looked at it. Think it’s time I visited the bakery.
But, but.. we were told NodeJS was "fast enough".
Good stuff, this could be a great time saver.
Thanks for the birthday present, gonna try it soon, it solves most of my pain points with pnpm with a few nice bonuses
I was quite sceptical of another JS runtime, after not getting much benefit from Deno. But run/build/install times with Bun blew my mind, especially with typescript.
Apple’s webkit is finally getting appreciation
I think it'd be cool to see a video on benchmarks. I see a lot of back and forth about this stuff: how useful they are, how they should be interpreted, what makes for a good benchmark, etc.
Yes, please share future insights on buns real performance difference!
Its soo fast and nice. The file api is also very nice to use. I upgraded a websocket server yestday to use bun. There was one incompatible dependency syncfile read but I could actually remove this dependency because bun has the build in prompt function which is very nice. I could throw away a lot of code actually and it starts up like 4 times faster. Great!
This looks really interesting, some of the features would make it a node killer for beginners too because of all the frictions and headbanging stuff that makes the developer experience for those users really painful, if it weren't for the Windows thing which probably many beginners are using.
Thank you for making me waste 3 days trying to get it running. It's not ready!
Important note, bun on windows wont be as performant as it will get in the future as jarred decided he doesnt have enough time before releasing 1.0 to understand how to write fast I/O windows code, so they for now use libuv (what nodejs uses for the I/O)
Gonna try this with a game engine 👀
But Bun allows you to just remove your node_modules and install them again in a fraction of the second once you get back to the project to save on disk space :)
bun is just awesome for library devs easy setup
It's wild that this started as Jared just thinking "esbuild is cool, lets see if I could make that in zig"
Bun is showing us what javascript could be if every API is implemented natively
But at the end of the day, normal js code will still be slower, it's just not slow enough to ditch it
still way faster than Python.
Just added bun to my workflow and its been great so far
Killer feature is the easy way you can write the hard stuff in zig, and import it as an esmodule to use in a scripting language.
Has the potential to overtake python in machine learning.
Faster and safer than Rust, with a much better dx
How is it safer than Rust?
@@davidt01 yeah well that’s potentially a very long conversation that can go sideways quickly. If rust’s concept of safety works for you, then go for it. There are alternative opinions though.
@@steveoc64 Well from my understanding, Zig has manual memory management, which is inherently not as safe.
@@davidt01 while it may have manual memory management, it has a lot of in-code ways to help you making it safe, and the compiler alerts if there's a memory leak.
Thanks!
Wow! This sounds very cool. Let’s see how it works with bigger more realistic projects
Bro, it's just websites man.
Back in the day we had a project that could reload once for 2.5 minutes. Now people consider using something that instead of 6 seconds installs something in 1 second.
Elephant in the room: Electron. Think of how much you are losing by leaving that behind. If you care about using your existing codebase as a feature complete desktop app, it's a dealbreaker. I don't see any path forward for this either :/
I'd definitely switch to Bun for my full-stack applications when they support Solid-Start. As of now, Bun can initialize a Solid-Start project but cannot run it. Node.js runs under the hood, even when I type `bun run dev` command.
I've run into similar issues with `bun create preact`. This is the same sort of issue I've always run into getting Bun to work on projects since it was first announced. Some key step is just outright missing or incompatible, and the workaround is to tear apart the `npm install` or other such process to track it down and "fix" it. This is just to init a toy project.
It's really disappointing. It all sounds great if you're building without a template from scratch (maybe) or if Bun-specific templates are created in the future, but I figured the whole point was to not have to get "Bun-specific" with everything.
you need `--bun` flag there
I was just at the bun website, I thought let me watch some videos on youtube on it, open youtube and this video is at the top.
Does vercel have plants to add Bun as runtime option?
I think tmux has a feature to send keys at the same time to panes, no nees to switch and click
Bun + Linux === Perfect! Your TS/JS frontend/backend all run on Linux anyway!
Is incredible that Theo consider himself a open source mantainer, while having Mark and Julius do all the work 🤣
He opened a great PR to turbo recently.
Open source manager.
that's funny
Project management is tedious, don‘t underestimate it
@@MajorBreakfast He doesn't manage it
Old dev here... what a day be alive. Complaining about 6 seconds over 0.24 seconds. New dev issues :)
I honestly do not care that much about the performance. Node is maybe slow compared to bun but it's fast enough for most server side apps.
But the Tooling, OH THE TOOLING. This part got me so excited. The number of hours I've spent in my career setting up parsers, compilers, bundlers, dealing with commonJS/esModules, and then fix it when they break due to some weird dependency.
This whole concept of not needing to download 37 modules before I even write a single line, just for the tooling, is soooo freaking compelling.
i was waiting for your vid after 1.0 dropped
8:09 hopefully they'll add a `--force-symlink` flag then or a global config (for people that'd prefer disc space over speed)
best hairstyle yet
The bun library is nice, but it has analytics active by default, which means it spies on you. Additionally, it is not compatible with NestJS, despite claims to the contrary. I wouldn't trust using it in a project for anything more than running files; it's not suitable for a real project. Bun is also backed by Y Combinator, which creates a potential conflict of interest with Theo.
Great now we just have to wait until 2040 before AWS supports bun in beanstalk.
Well, seems like I'm moving to bun...
As I see your video I have a feeling that everything Bun just solves now out-of-the-box should have worked as is before. I'm just wondering why the whole previously existing ecosystem is so overcomplicated...? It's so funny when you stopped for a moment on the fact that Bun can combine requires and imports in the same file and... wow...! Incredible :)
Poor Deno...barely existed
Real world project benchmark test results after migrating to bun::
Node.Js
Total: 97.5701 secs
Slowest: 0.3324 secs
Fastest: 0.0326 secs
Average: 0.0488 secs
Requests/sec: 1024.9041
Total data: 1.08 GiB
Size/request: 11.29 KiB
Size/sec: 11.30 MiB
--------------------------------------------------------------------------------
Bun
Total: 77.8154 secs
Slowest: 0.2495 secs
Fastest: 0.0261 secs
Average: 0.0389 secs
Requests/sec: 1285.0923
Total data: 1.08 GiB
Size/request: 11.29 KiB
Size/sec: 14.16 MiB
--------------------------------------------------------------------------------
Elysia
This is a complex application with all kinds of validations and db calls. The migration took around 5 mins but the results were good enough. Keep in mind this is an express application and I'm planning to migrate to Elysia soon.
What are you using to benchmark?
JS/TS is going places!
I don't get the last paragraph.
Bun is made using Zig.
Zig/Ruby and Bun have different uses.
thats like a 20% increase overall, feels too good for a drop in replacement
@@coffeefpsHe means actually writing zig code instead of the step between by using bun which is run by JavascriptCore
Can you make a video about running bun on an existing project and see how the transition from webpack to bun-dler is? Thanks!
Thanks for such an insightful video, I share your excitement! I'm wondering how easy it would be to move a ViteJS app and test performance gains.
FRONTEND IS SO WILD --- Things getting smashed in benchmarks every month
Wonder if Node will catchup. Its looking like a head to head against Bun and Deno
let's tell ourselves the truth, many people aren't actually using Deno tbh
@@wisdomelue And more people are giving up Deno.
Well it took NodeJS like half a decade to add built-in Fetch support... so they have a lot of catching up to do
just tried to run my nextjs project with bun and it just worked ™ I think node is done.
Does hot reloading works, cause it doesn't work for ne
Very interesting. Would like to see more Bun vids
it defaults to fast copy, but that's configurable, you can choose to use hardlinks anyway
Time for some prototyping….
they took blazingly fast seriously
Some months ago, Jack Herrington tried Bun against Deno and Node, and he faced a lot of segfaults with Bun, besides some other weird behaviors. Hope they fixed those things by now.
Stuff like SQLite has some crazy assumptions like unexpected caches and stuff wonder how they wanna fix these issues without effecting performances
Someone said "File cloning on mac OS is essentially like hard linking with copy-on-write. The one downside is that the filesystem doesn't support this for folders."
Is this true? If yes, then you could switch to bun in macOS and not worry about disk space usage. Maybe you could test it out.
Is there any version of bun runtime for serverless functions similar to cloudflare's isolates?
can i really trust Bun to send apps to production?
I tried yesterday to add two private registrys It's a nightmare
The documentation is so bad
Did you figure it out?
nice new challenger!
I hate JS, but bun still managed to make me exited, and create some test projects to see how it works
wow. just wow !!!!
12:35 of course
Can we use Bun in Vercel?
But looks amazing for anyone who doesn't want to learn how to wrangle the other bundlers but occasionally wants to use JavaScript for simple pages
Disk space usage is also as much an important concern as performance. I think it's a little blindsided to always prioritize performance no matter what. Balance is key, so the question is: Why didn't they give a global option in macOS to do hardlinking instead of cloning files? (If a developer like you doesn't want cloned files all over your disk, and is willing to accept the lower performance, why not?)
Also, can you just hardlink yourself later? Will it work?
I guess the question is why do all of your projects need 2-500mb of node modules...
Well time to rewrite all my projects from Node to Bun before the market gets floded with Bun positions.
Still waiting for fully support with Vite.
bun intended haaaaaaaa
ive been doing this now for about 6 years, and in the js, go, and rust world. i can't believe how many things are in js. i started w/ js so i thought this was normal but it is true some package is released like every month lol. this looks great but how do we know this will be around in 5 years
Bun seems tk just work tm
What blew my mind is that you import Rust functions, just like that.
Bun even works on laravel.
I would like to see if you can adopt just parts of Bun not the whole thing. For example, would it be viable to use just the built-in test runner to write tests in an existing Node based project?
Great video btw
bun is so fast wtf
Can you share link to the project you tested install speed on? I’d like to test it with yarn 4 in pnp mode with global cache (which I guess you didn’t use in the comparison) as it’s cached instal is super fast
Waiting for some websocket benchmarks. Supposedly they have a faster version of express?