I don't know about all the points made in this post.
Bun is not the solution to everything, but the speed benefits it give to scenarios like a replacement to jest are well worth it for me and my team. I love that fact that is a set of tools that you don't NEED to buy fully into.
Regarding No Version Manager, I don't believe it is a priority to built a version manager when version 1 is only 1 week old, I think that would probably be more useful later on. I believe they're being pragmatic and releasing something usable that is stable. It's probably better than delaying a stable release with slightly more feature by 6 months.
Otherwise great article and I look forward to coming back here and seeing how many of your predictions come true, especially the Breaking Bad part.
Keep up the good writing! I enjoyed this and just wanted to mention my thoughts on some of the points here :) I do hope (and believe) that some of the things that Bun brings to the table does make it's way back to improving NodeJS.
I would just add that if, according to this article, it took NPM 5 years to catch up with Yarn, probably it would have taken 10 year to achieve the same progress if yarn was not introduced. I would say the same thing for Node.js even if some day catches up with Bun.
IMHO, In overall, competition is the driving force behind remarkable innovations and progress and these diverging paths from the mainstream often bring significant value and who knows, It might become the main stream itself.
Speaking of Tailwind, I was one of those developers that thought, it was the worst thing that had happened to web development, until I " suppressed the urge to retch" it and tried it. Now I can not go back to writing vanilla CSS.
i'd imagine the idea is that the Yarn devs should've contributed those features to NPM directly. that said, idk how contributor-friendly the NPM team is. some core teams, like PHP Core, sort of meander until they're pushed by the threat of competing projects (in PHP they had to contend with Hack, which was much faster and had some nice features PHP lacked, and PHP quickly addressed these in PHP 7 which kept most PHP devs around; Hack now looks like a different language to a degree, afaik is only useful to Facebook). sometimes the threat of splitting the ecosystem is a good thing, but shouldn't be wielded as a first option. and in defense of core teams, having companies like Facebook threaten to split your ecosystem if they don't get their super specific features/changes (that sometimes don't benefit anybody but them) is also pretty gross so i don't always disagree with telling them where to stick it.
Definitely an interesting article, and @barrymichaeldoyle I definitely agree that while Bun isn't the end-all-be-all, it certainly offers an excellent (and fast!) alternative for devs to utilize instead of the vast web of Node components.
I've recently started building a number of project updates with Bun as a drop in and the reduction of time to test and build has been pretty darn impressive! Granted, most of these projects aren't exactly "huge"....even still, it's extremely noticeable how much quicker the process is regardless of the overall project complexity!
The smaller the dosage you use Bun, the lower the risk. If you go all in, and use every feature it offers exclusively, then you are at high risk for running into the pain points outlined in this article. If you are able to replace a feature Bun offers with a different approach in a reasonable amount of time, and be back to normal, then I think it's totally valid to adopt it for that use. I hope you and your team get some value out of Bun and don't run into any of the problems I'm worried about.
Yeah in our specific case we've given it a shot to replace jest and it was as simple as a plug and play, it works pretty much exactly the (except it's quicker) and we haven't had to change any of our existing tests. The only difference of using Bun has been that we don't need use all the config for setting up jest that we had before. For now we'll keep the Jest config in-case we try to revert.
Ah right, that makes sense why the bun hype is there. Yeah I'm pretty much all in on TypeScript so I guess that puts bun right back up there for my test runner of choice :)
You have identified a problem with TypeScript, not with Node. TS has always been excruciatingly slow. Many are now switching over to JSDocs for type management. It has many benefits over the TS Language while still being completely compatible with the TS Engine and tsc. However there is no build or runtime cost. You can do enforcement of keeping your JSDoc comments up-to-date via a simple linting plugin. If you don't want to configure all the linting rules yourself, this is the easiest 2 step process to get started github.com/tjw-lint/eslint-config-...
I don't know about all the points made in this post.
Bun is not the solution to everything, but the speed benefits it give to scenarios like a replacement to jest are well worth it for me and my team. I love that fact that is a set of tools that you don't NEED to buy fully into.
Regarding No Version Manager, I don't believe it is a priority to built a version manager when version 1 is only 1 week old, I think that would probably be more useful later on. I believe they're being pragmatic and releasing something usable that is stable. It's probably better than delaying a stable release with slightly more feature by 6 months.
Otherwise great article and I look forward to coming back here and seeing how many of your predictions come true, especially the Breaking Bad part.
Keep up the good writing! I enjoyed this and just wanted to mention my thoughts on some of the points here :) I do hope (and believe) that some of the things that Bun brings to the table does make it's way back to improving NodeJS.
I totally agree with you.
I would just add that if, according to this article, it took NPM 5 years to catch up with Yarn, probably it would have taken 10 year to achieve the same progress if yarn was not introduced. I would say the same thing for Node.js even if some day catches up with Bun.
IMHO, In overall, competition is the driving force behind remarkable innovations and progress and these diverging paths from the mainstream often bring significant value and who knows, It might become the main stream itself.
Speaking of Tailwind, I was one of those developers that thought, it was the worst thing that had happened to web development, until I " suppressed the urge to retch" it and tried it. Now I can not go back to writing vanilla CSS.
i'd imagine the idea is that the Yarn devs should've contributed those features to NPM directly. that said, idk how contributor-friendly the NPM team is. some core teams, like PHP Core, sort of meander until they're pushed by the threat of competing projects (in PHP they had to contend with Hack, which was much faster and had some nice features PHP lacked, and PHP quickly addressed these in PHP 7 which kept most PHP devs around; Hack now looks like a different language to a degree, afaik is only useful to Facebook). sometimes the threat of splitting the ecosystem is a good thing, but shouldn't be wielded as a first option. and in defense of core teams, having companies like Facebook threaten to split your ecosystem if they don't get their super specific features/changes (that sometimes don't benefit anybody but them) is also pretty gross so i don't always disagree with telling them where to stick it.
Definitely an interesting article, and @barrymichaeldoyle I definitely agree that while Bun isn't the end-all-be-all, it certainly offers an excellent (and fast!) alternative for devs to utilize instead of the vast web of Node components.
I've recently started building a number of project updates with Bun as a drop in and the reduction of time to test and build has been pretty darn impressive! Granted, most of these projects aren't exactly "huge"....even still, it's extremely noticeable how much quicker the process is regardless of the overall project complexity!
The smaller the dosage you use Bun, the lower the risk. If you go all in, and use every feature it offers exclusively, then you are at high risk for running into the pain points outlined in this article. If you are able to replace a feature Bun offers with a different approach in a reasonable amount of time, and be back to normal, then I think it's totally valid to adopt it for that use. I hope you and your team get some value out of Bun and don't run into any of the problems I'm worried about.
That's a very mature point.
Yeah in our specific case we've given it a shot to replace jest and it was as simple as a plug and play, it works pretty much exactly the (except it's quicker) and we haven't had to change any of our existing tests. The only difference of using Bun has been that we don't need use all the config for setting up jest that we had before. For now we'll keep the Jest config in-case we try to revert.
Nodejs has a fast built in test runner.
How fast is it compared to bun and how much config setup does it require to run alongside things like RTL?
I saw a comparison in this video.
But it does not work with typescript code.
If you have to compile your code first -> its like 10x slower instead.
Ah right, that makes sense why the bun hype is there. Yeah I'm pretty much all in on TypeScript so I guess that puts bun right back up there for my test runner of choice :)
You have identified a problem with TypeScript, not with Node. TS has always been excruciatingly slow. Many are now switching over to JSDocs for type management. It has many benefits over the TS Language while still being completely compatible with the TS Engine and
tsc. However there is no build or runtime cost. You can do enforcement of keeping your JSDoc comments up-to-date via a simple linting plugin. If you don't want to configure all the linting rules yourself, this is the easiest 2 step process to get started github.com/tjw-lint/eslint-config-...Bun still seems like a more elegant solution to my TypeScript problem though.
I'm personally not a big fan of JSDocs as a replacement for TypeScript in its current state.