100 Days of Node.js vs Bun - Who is the winner?

so bun has completed officially 100 days of its V1 release and I just wanted to visit back I know like have talked a lot about bun on this channel and we used it in our own production workflow so I want to go over through what happened in these 100 days what decisions are we taking and what is my review of bun as a technology so for those of you who are new here my name is mayle I'm the founder of codam and we run a website where people learn to program right and as a website where we have built a lot of tooling from AI to in browser IDE to coding Labs we have a lot of repos where we can try and experiment new technologies and Bun was the perfect candidate for us not only because most of our codebase is in typescript but it also suffers from all the problems which bun lists to solve right faster package installation outof the boox typescript support basically a toolkit in itself which helps you do nodejs work faster because our front end and back end everything is in JavaScript so it was the perfect tool for us we tried we started using it but there are a few things which I want to share in this video so here we are let's try to understand what this technology is how this is working and should you be using this technology in your own production workflows today or not so if you look at bun 1.0 it was released back on September 8th which is more or less 100 days from this video so it has like gotten a good solid 100 days of more time from the wii1 my number one thing with bun is that it's an amazing package manager right there is a clear difference when you install packages with bun versus when you install packages without bun there is a clear difference in speed next comes the part where bun is an amazing typescript Runner well not really because once you start to use bun with typescript what you will first of all realize is that bun I'm just talking about this in terms of typescript as you know you running a typescript file bun is a fast wrapper around es build and running it with node right because you can't technically run typescript natively you have to compile it down to nodejs and then use you know JSC or web kit which bun uses under the hood which then you know runs nodejs because the engine doesn't understand typescript the engine needs JavaScript so you need to compile it down to JavaScript I'm saying nodejs by mistake it's actually bun bun is a different runtime so it just needs JavaScript and then you run that now the problem that happens when you run things with bun in typescript is that you come to a point where bun you will find a package which bun does not support and the reason it does not support it is because bun does not support that package inside nodejs itself right so for example I think this is this has been very recently fixed but Json web token the very popular package on npm which is used for you know encoding and decoding data in Json in JWT so you see one of this issues which was opened on by Jared himself on 10th February it was recently fixed where ban did not support JW Beauty right so this Json web token package because it did not support something under the H which JWT this package was using with node with node compatibility so this is one of the things which blocked us from using bun in our own back end for using it as a first class runtime in the development build space of course in production we will build and bundle it and use you know as we use AWS seress for hosting our back end so we will do that on the production we will build it and run it via node but in development itself we we thought that it would be very easy for us to you know just write all the code we are doing in typescript then use a technology like bun and just start our Serv directly instead of compiling it to JavaScript and local environment also but it did not work right once this was fixed I don't remember exactly but there was another breakage which was happening in I redus package if you go and search for I redis on B issues you would probably see that also let's see if we can find that so I don't exactly remember which issue was this but maybe it's also fixed now but it was also an issue which we got stuck with so finally what happened was that even though it appeared like one version one is here it's an all in one tool Git it has full nodejs compatibility I think they also wrote it B is a drop in replacement for node it's not the case even with version one and even 100 days in this is not the case so this was our first setback with using bun as a technology right when we realized that it's an extremely fast package installer which I'm not taking any credits from it some times you know there were a few occasional bugs where it would hang and it would you know crash here and there but I think that's mostly fixed now points where it's due it's an extremely fast package installer it's not a good runtime environment for production use cases for a back end for a front end which is using a lot of common nodejs modules node npm modules and they rely on nodejs fundamental you know nodejs few internal Technologies like node crypto or anything so these are the Technologies or these are the packages like node crypto you probably would not use on your own in your you know in your basic card app so if you're creating let's say a login form and a database and a backend you would not use these packages but what you would use is bcrypt what you would use is Json web token what you would use is IUS right these softwares these packages with millions of downloads every week and then you will figure out that bun breaks them or bun is not able to run them because of some issues here and there now in buns defense I can say that you know they are shipping very fast they are fixing bugs all the time they're releasing every every week or so but look at this from a company's perspective look at this from code Dam's perspective changing a company's tooling or you know creating an infrastructure takes a lot of time right and when we try to shift it from let's say if we saying that locally we don't want to try es build we want to shift to bun when we make that change and that doesn't work out and then we revert back decision makers developers they would probably not touch that technology again for at least a few months if not not years because I'll tell you why I I'll tell you why this this is something which uh bothers me and the team at code dam is that we also did a lot of effort on changing our code base from poly repo to monor repo like just a couple of months back so we shifted everything we had like tens of repos across every single you know micros service and AWS Lambda every web Hook was its own repo in in a way so all of that was a mess we combined that into a single monor repo which was pretty solid then we tried using bun because of various reasons and it did not work out then we had to develop our own you know the own pipeline of how do we use this system locally how do we build it how do we deploy it and then tomorrow let's say bun comes out and says I have fixed this one bug which was your blocker it becomes extremely hard for us to justify that you know let's just go ahead and try this again because it's just a lot of hours wasted right now we have got a setup which is 20% slower on locally so hear me out when we say 20% slower it's also important to quantify how much that is right so if it's 100 milliseconds nobody cares right if you are booting 100 milliseconds slower on start time and then it's equivalent in speed we don't care as long as we are getting a solid tool chain which is nodejs right so in a way that is what did not work out for us that when we tried bun it broke due to a lot of compatibility issues with node and generally speaking bun also has a lot of bugs right for example one of the bugs which was found by one of the people we have on the team so what he figured out was that there was a very edge case scenario where bun was not printing length of a you know when you're using console log which of course clearly worked in note JS now I'm not saying that this is a huge thing or this is a you know a deal breaker or anything but it just shows you that there are a lot of subtle edge cases there are a lot of things which can go wrong when you're using a run time which is as new as ban and you will waste a lot of your own time on the expense of on the on just the premise of that you get a faster solution there also have been instances where people were trying something on COD Dam playground on buan and it just didn't work and you know the CLI froze and something happened and we were figuring out if it is our fault if the you know the code Dam playgrounds which is a way to try out anything in your browser any sort of technology in your browser if we were at theault right and it turns out that we wasted hour a couple of hours and then we figured out this is the same behavior when you try bun outside of codam playgrounds so it's a fault with the bun with the bun software not with the codam playgrounds in general so long story short this has been like an experience for us where bun sounds great on paper bun is a great package installer as well I'm not taking away that but it's it's very very brutally speaking it's not a great runtime it's not it's just not the final nail in the coffin for us with banjs was just a few weeks ago when suddenly what happened was our GitHub action started failing like it randomly started failing so you can see about 2 weeks ago you can see that we had our last successful build on Master then after that all of the builds started failing for some reason right and if you go into these bills what you will see is that these bills over here they just fail randomly we use monor repo and turbo repo setup but if you see they just fail randomly with segmentation fault and we had no idea what's going on this particular thing was working just fine for months for weeks and uh it just started failing one day and then it just kept on failing at least until the point where we debugged like what's going on what's wrong with this and it turns out by the way that we were invoking our build script with bun and we shifted that to nodejs I'm not saying that this might be a fault this might not be a fault maybe this is GitHub actions fault but it it will be hell of a coincidence if it was because the moment we shifted to nodejs we did not get a segmentation fault again on on our build steps right so this was a final nail in the coffin for us from shifting our tooling from BJs back back to note because it felt like it we are just trying out a tool which has infinitely many gas when you try to use it as a runtime and it's just not stable enough for a lack of better word right now and if you go to buns repository and search for memory or segmentation fault you will find a lot of issues still open from months which have not been closed because memory management and segmentation Falls in general are very tricky issues to track and fix right so there's that so the question now is what are we using if not bun because bun brings a lot of interesting benefits right what we are using as of now I mentioned that we are using a monor repo setup so we have to use a package manager which is good enough for handling monor repos bun by nature is it's it's fast and it's good but it does not support monor repos right now so it's not a choice for us the next obvious choice was pnpm so that's what we are using dedicatedly exclusively right now pnpm is great it's not as fast as bun I admit that it's actually relatively slower if you compare it one to one with bun but it it gets the job done it's very stable it just installs it it just knows what to do it's very dis efficient does not take a lot of space and it just gets the job done it has great monor repo support exactly what we need for running our typescript files directly what we use is TSX so I have a small confession to make I did not know about TSX before and internally what we did is we developed something of our own solution which was exactly how TSX works right so what we would do is we would compile all of our project in monor repo with es build very fast ly and then we will invoke it via nodejs right we did not know a solution like TSX was there so think of TSX like buns runtime environment the only difference is is that it just runs using node internally and it's it's slightly slower so when I say slightly slower you're competing with es build it'll be a difference in milliseconds and a few milliseconds like 100 200 milliseconds and to be very honest we observed no such impact on our productivity as developers working locally it's very fast it boots Within milliseconds our local server starts without any hesitation and that's it it just supports Everything Note supports and that's exactly what we need right every single thing working just like how we would suppose it to work so we are huge fans of TSX now we use it very very much in our local development setup for invoking any sort of typescript script it works great it supports this common jsn esm thing which bun also supports it resolves TSC config.js it works very properly with that so that's that's a great thing as well and most importantly it uses is nodejs under the hold which is the most important part for us so to summarize we don't use bun anymore what we use is Turbo repo for managing our monor repos what we use is TSX for invoking our typescript code and what we use is pnpm for installing and managing our packages in monor repo we have completely removed bun from at least from our build pipeline bun is still available on code Dam playgrounds and we love the fact that it's so fast you can try out Bun over here on codam playgrounds for free it automatically up updates to latest version It's a Great Piece of software but it feels like it's a faster and a broken version of a lot of things combined I know they will fix it I know window support is missing a lot of things are missing and they will fix it eventually but what I feel now after spending like over 100 Days with a 1.0 stable version of bun is that that at least for now it's not usable for any sort of sophisticated production app it is usable in a very few specific work cases but even in that I mean the cost of switching your run time let's say if you have a very solid tooling with TSX and uh es build and everything and then you introduce try to introduce bun it'll be a very hard sale right because even on CI for example most of your time will never go spending and installing packages because almost everyone caches that step right and most changes never happens where you are installing or removing packages rapidly pnpm is slower but it solves that it it solves that through it central store and it's you know it's just installs you will get a few seconds sure on CI but nobody's watching that timer on CI right everyone wants stability and speed locally stability is to be very honest out of the window right now when you're talking about large projects with a lot of node modules and a lot of things when you're running with bun and very honestly speaking fast code which is not stable is not good enough for any use case whether in development or in production so these are my honest views with bun and uh like I said it's a great piece of technology it has a great piece of you know engineering associated with it I know how much effort and how much time and sweat and Blood and Tears it takes to build a software like this so I want to see it succeed I really do but it's just not ready right now what do you think about this do you use bun in your own production systems or have you tried it locally I mean it works great with small Snippets but anything specific which you found great or annoying with bun let's discuss in the comments below that's all for this one I'm going to see you in the next video really soon

Channel: Mehul - Codedamn

Views: 31,725

Keywords: mehul mohan, codedamn, bun, 100daysofbun, what is bun, oven.sh, bun.sh, web development, bits goa, full stack web development, learn how to do programming, how to code, learn coding for beginners, production, backend web development, web development roadmap, javascript, how to learn coding for beginners, web development tutorial for beginners, free web development resources, bun runtime, bun javascript, software engineer, html, react, full stack developer, frontend, mern stack

Id: x1iXA041zM4

Length: 15min 12sec (912 seconds)

Published: Wed Dec 20 2023