Here we go again, making the same mistake. I'm constantly reminded that every 5 years the amount of programmers in the world doubles, which means a...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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!
Nodejs has a fast built in test runner.
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.
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.
I can't find on Bun's site that they use WebKit engine. I see:
My personal opinion is that Bun is trying to build too many things around it, like TypeScript. Which effectively leads to so many distractions instead of focusing on core, stability, and performance. It will be a huge ballon that will eat memory with probably 70% of features not used. There will be quantity over quality. At the moment of writing this comment, there are 1590 open issues and 1703 closed.
At this rate of bug growth, Bun will spend more and more time fighting bugs rather than stability and performance. Let's assume that it takes 4 hours to fix each bug (extremely optimistic), that's already 6360 hours spent just on fixing bugs. Let's keep counting, 8 hours a day, that's 795 days! 795 / 365 gives you over 2 years of work just to fix 1590 bugs!
And it will keep growing, as implementing too many features is just a consequence of that.
To the whole great post, I'd also add the overhyped Tailwind, which literally does nothing new and makes the whole development even worse. See example:
flex transition-all dark:bg-darkNight bg-white duration-1000 relative 4xl:max-w-11xl 4xl:mx-auto 4xl:shadow-xl 4xl:rounded dark:shadow-4xlvs.
chat-messageTailwind complicated development 10 times by moving from logical to illogical order. What's wrong with reusable classes? What's wrong with named CSS classes? Instead of first looking at named classes to understand what follows, the engineer now needs to spend time decrypting the intention of the implementation behind all CSS classes. It should be the opposite: Read the name of the class. Interested? Dive into implementation details. Not interested? Keep searching. That approach allows you to quickly scan the app logic without diving into implementation.
To quote trac.webkit.org/wiki/JavaScriptCore
@mellen Thank you!
You can always compose your own additional css class from tailwind css utility classes. What’s wrong with that approach which can be applied to such cases with classes that are too long/unreadable?
This is outside of the scope of this article. However, I would note that Tailwind's create (Adam Wathan) has specifically said that what you are advising is an anti-pattern and that
@applywas only added to trick people into using Tailwind that did not like their HTML being littered with dozens of classes. His words, not mine. Source@thejaredwilcurt
That's for sure. However, I'd really love to hear what kind of problems Tailwind resolves that existed before.
If your company was using a css framework before, tailwind is solving that.
pb-3in bootstrap... what does the 3 mean? It means whatever your default size is. But what if you want something bigger?pb-4? But that's too big.Tailwind solves a lot of that.
I thing it should not be that much treated as the only way. If you need couple of composes classes - world will not break. You definitely don’t need to make own class for each element in the tree - it’s for sure is not as it supposed to be done. But just few classes for very long class names - it’s fine I think.
Because this Tailwind is more understandable?
h-screen xl:min-w-282pxl xl:w-260pxl hidden xl:block overflow-y-hidden dark:bg-darkNight dark:border-matteGray font-ubuntuI love Tailwind and SASS, but they have trade-offs. Tailwind offers scalability and maintainability, reducing the complexity of naming conventions.
If your project doesn't scale, then Tailwind may have more cons than pros, as it truly shines when maintaining large codebases with specific needs like SSR or performance.
I understand that it can be cumbersome and verbose to write styles like this, but using them at the right moment can be a lifesaver.
I think it's really important to know and experiment about everything that you can to know what these cons/pros are and understand what it's the right tool for the job.
@pablets Would you mind to explain what kinds of problems exactly does Tailwind solve?
The "scalability and maintainability, reducing the complexity of naming conventions" doesn't explain the issue and what kind of solution was invented by Tailwind to resolve it.
Is this
bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20called a "reducing the complexity of naming conventions"? If so, how so?Can you give an example of scalability challenges and how Tailwind resolves them?
I'd appreciate it.
@andrzej_kowal
Composing your own CSS class was available long before Tailwind was born. My primary question is: what kind of problems does Tailwind resolve that weren't resolved before?
By making styling more visible and flexible, and limiting cognitive load. When working with a massive component-based SaaS codebase and an immature, unstable design system, I want to see styles in the DOM template of the component where they’re being applied without having to reference several different CSS files written by different authors at different times all applying globally what they thought could be taken for granted finding myself in CSS cascade hell trying to implement something new without breaking existing legacy UIs or take on the complexity of the entire system.
Pure CSS is beautiful and I can’t wait to ditch Tailwind… later, when the design system is mature and my UI is all nice, clean components, and what a joy it will be (and so easy too) to replace all of those tailwind classes with clean, structured CSS. But honestly, if I never get there, Tailwind will be just fine.
@stephenhebert Tailwind does not resolve the problem you described. Frameworks like Angular, Vue, and React do. You can encapsulate your styles within components. Even Web Components can be used today. Even using only Sass you still can structure code well.
By making hundred different small classes used within one element, it is extremely difficult to understand the semantic and expected behavior. The code should present the logic first. Implementation is important only when you want to dive into code changes, behaviour, or the like.
@stephenhebert , Tailwind does not decrease cognitive load. It does the exact opposite. I want to see less code, and more business.
Check this article from creator of TailwindCSS.
link.
If you guys would like to know what TailwindCSS actually do and why, it might be a good idea to get on their official website and read by yourself.
The idea behind Tailwind described by inventor isn't convenient to me. Let's move that discussion to some other relevant post.
I think you looked at this syntax
"bg-white dark:bg-darkNight dark:border-matteGray border-b border-grayLighter w-full flex justify-between px-2 py-3 items-center xl:hidden fixed top-0 z-20"and become a hater just because it looks ugly.But you forgot the benefit from it:
@ginkcode "All of these configs are very clear, when you get the hang of it you can imagine or figure out how the element looks like exactly at the same time writing html code. "
That's the most unneeded "feature." You should not read the code to determine the meaning and expected action of a particular element. Those small classes are related to one (in general) case, and later, with the combination of all of them, they create a single element with its behavior. I don't see any advantages to having 20–30+ micro CSS classes and forcing the software engineer to read and analyse the code to find out what it is and how it behaves.
"And more important thing, IMHO, the visual and preciseness of those tw classes, it's defined right on that element and belongs to that element only."
No, they are shared classes. Anything you change in one class affects all places where it is used. Single classes, like margin or font weight, used alone might be applied to some specific cases, e.g., components used only in one place. Or you're adding modifications to some old code and you don't want to change the main element's CSS class, but rather just add one style.
"Everything will end up as a mess and very difficult to find out the reason."
Properly structured and organised Sass will make everything perfectly understandable, manageable, and easy to maintain. Using 20 or more microclasses makes the code very hard to understand and manage, unnecessarily increases the HTML size, and may, in some situations, also impact the performance.
You're talking about css shared classes. TW classes are different, I never think of any developer will ever try to override TW classes. They should be out of mind.
Anyway, if you prefer to work with Sass then that's your choice and no one is against that.
TW has proven its usefulness to the community and is well received by the developers. That's why it become so popular.
@ginkcode
Aren't TW classes shared? Is overriding an unnecessary and never wanted need?
Sass has nothing to do with TW. Sass organising your styles and working on them.
Popularity doesn't mean something is good. This has never been the case.
I'd be happy if you could provide a table with 2 columns: [Challange] [How TW resolved it] in the below post.
I'd propose to move topic-related discussion to: dev.to/cezarytomczyk/tailwind-over...
The entire idea of calling it a "drop-in replacement" is ludicrous. It just isn't, if you're forcing me to change my imports. Perfect example: I have an npm module that's a wrapper around better-sqlite3. I've been developing it for years, it has 5+ million downloads, and it works great.
Someone opened an issue asking that I "add bun compatibility" which of course is idiotic : if Bun is a drop-in replacement, why the hell would I need to change anything? So when I said "no, let them be compatible, I have no intention of doing this sort of development effort" the person just forked my repo and made a bun-compatible version by switching the imports to bun:sqlite.
Now you might ask, why do I not feel like doing development effort here? Simply put, I'm on Windows, and I'm not about to install a different operating system (Virtualized or otherwise) just to make a supposed drop-in replacement actually work when dropped in. So... nah. No thanks, Bun. I'm good.
Thanks for this real-world anecdote. There are many other people in the comments claiming Windows support isn't worth Bun's time, but ultimately it will be the reason why they won't be able to overtake the much more mature, stable, and fully cross-platform alternatives.
I spend extra time making sure all of my libraries run the same on all platforms. Or include all platform specific options for those types of cases. I'm very proud of how most of the Node ecosystem has done the same. All platforms being treated equally.
Having been around for a long time, I find it especially funny how the Linux community used to complain in the 90's and 2000's about no one taking them seriously and supporting them. Now they are on the opposite end of that table and arguing against adding support for Windows. They didn't want all OS's to be treated equally, they just wanted stuff to work for them. Which is the same thing they complained about of other non-Linux users. Fascinating, and sad.
I foresee a lot of libraries getting
if (bun) {} else {}added to them. I don't think that's a terrible thing, in general, it's much better than the alternative of only supporting Bun. However, like with any project, the larger it gets, the more effort will be required in maintaining this additional feature (Bun support). And at some point, when Bun starts to die off, they'll need to do a major bump release to convey deprecating support for Bun. It's a choice people can make, to offer additional support in the short term and opt-in to future tech-debt.The statement that C++(Node), Rust(Deno), and Zig(Bun) can all reach the same level of performance is very accurate.
This is because they are all compiled to the same LLVM backend, which is a compiler framework for C and C++.
einventing the wheel is often worse than the existing wheel that is understood and maintained by many users.
This article is very insightful, but it's a shame that I, who am not a native English speaker, can't appreciate the many jokes quoted in the article.
I really struggle to see the relation between production ready and Windows as target ... software developers are rarely on Windows (or let's say these are less frequent) and Windows has WSL which Bun supported for a long time. With this logic
curlis not production ready because it's not on Windows, or same goes for anything else Linux or macOS specific ... this argument is spread through the whole post and makes it less interesting imho, as you wrote many other interesting thoughts around the Windows thing but, if there's one thing that's not mentioned at all, is that NodeJS and the v8 team in general, if not the Web as a whole, really needed a fresh new take and look around a different engine (JSC, they always laughed at me in NodeJS or TC39 discussions when I've mentioned JSC as target for my JS, among GJS or others ...), a cut-the-crap forever ongoing discussion around ESM vs CJS (it "just works" (with a grain of salt) in Bun) and another cut-the-crap about standardizing JSX syntax in JS, something I've proposed to TC39 in a better and agnostic fashion but nobody is paying attention around this topic.Competition, the one you are against, is one of the reason npm became faster ... there were better alternatives that helped shaking/focusing the main/original project ... and same is the butterfly effect of Bun ... it's about the time some team realizes stuff can happen and such stuff can move pretty fast too ... and this is good!
P.S. I worked at NOKIA, we all know that story ... if teams and projects are really convinced nothing can replace them or make them obsolete and old, things move slowly, if these don't stale entirely, and nobody wins; thanks gosh there's competition and specially in these days were the fragmentation about everything around Web development is really something concerning, rather than being just "freedom of choice".
That’s such a relief to see a reasonable contrarian opinion around finally, thanks 👏
Great article but there was a point in your article -
The reason why Bun appears faster than Node.js in some cases is because Bun leverages Safari's WebKit engine. This engine, optimized for web-related tasks and JavaScript execution, can indeed make a substantial difference in performance compared to Node.js, which relies on the V8 engine.
It's fascinating how the choice of a runtime engine can impact performance, and Bun's utilization of WebKit certainly plays a role in its speed.
Yes it does! I skipped over that, but it's a very valid point. I'm actually most excited about their usage of Webkit rather than V8. There was a point where Microsoft had made a version of Node.js based on Chakra (Internet Explorer/Edge's JS Engine) instead of V8. And had Edge not switched to being Chromium based they would have continued to maintain
node-chakracore. I was very interested then, as I am now with Bun, on what unique, weird niche things one engine will excel at over another. Overall though I think most of the speed differences come from unoptimized Node rather than V8 specifically. This can be seen by how Bun allows you to use Node's API for Filesystem stuff, but even using Bun/Webkit it is still slower than Bun's custom native API's.But we'll see. Again, excited to find what weird things Webkit is better for over V8 in this new context. It will be a better comparison if Node renews a focus on performance, which I assume they will in the coming year.
Is V8 not « optimized for web-related tasks and JavaScript execution» ?
Compared to webkit javascriptCore it is slow
JavascriptCore has a faster startup time, otherwise they benchmark similarly. V8 is a HIGHLY optimized JS engine. Both have pros and cons
Agree with most of this, except for your comments about TypeScript ...
I think TypeScript is clearly and undeniably thriving - there's almost no major JS based frontend or backend framework that I know of that does NOT offer excellent and prominent TS support ...
From what I can see it clearly has a great future ahead of it - prove me wrong :)
Yeah, I would love to see a source for "TypeScript's usage plateaued around 2020" because everything I can find indicates it's still one of the fastest growing languages.
I don't think it plateaued at all, I think it's more and more becoming the default, especially for new and somewhat bigger projects ... I don't know what metrics he looked at, maybe Github stars or something, but with regards to practical usage I think it's becoming ever more ubiquitous.
My bun journey in 3 steps:
pre v1.0 ... i simply tried it as replacement for pnpm ... and found It's support for -C/cwd lacking
as v1.0 came:
today i tried
bun installon a codebase with private (freely accessible) registry ... found out bun ignores .npmrc ... .bunfig.toml doesn't fit into all other conventions ... aaaand it then still ignores that private registryWhile searching a solution ... i weirdly came here ... and will be sticking with pnpm, which is quite perfect.
Thanks for the real-world usage summary. Sad to see even more of Bun is hype than I initially even assumed. Good luck!
"a potential comment based ES202X official type system that will likely lead to a rapid decline in the need for creating .ts files" isn't entirely on the money. I took a look at the TC39 proposal and the proposed syntax is TypeScript (not to mention authored by TypeScript team). So no one is wasting their time by practicing their syntax now, and when they want to convert they can just
tscto the standard syntax and still use Microsoft's software as a "linter".I'd say this was always the master plan of TypeScript.
On the other hand, Bun has no such thing; like you say, if you use "bun.x" APIs you might be locked in. Which is pernicious because they market themselves as a "drop-in replacement" but are not quite as good as TypeScript in this regard.
As someone who tried Yarn as soon as it came out, I found that it neither worked as advertised (offline mode did not work) nor were the developers very responsive to GitHub activity. My brother and I whipped up a PR for them which fixes a bug with offline mode, and we heard nothing from them for an entire month before they simply merged it without any comments. I was expecting them to at least complain to us that we didn't write any unit tests...
I still don't really understand why Yarn exists to this day. pnpm has existed for longer than Yarn and solves an actual problem that I care about: saving HDD space. When I have hundreds of different small projects on my HDD and they all need node_modules, pnpm is really great. Plus their developer always responded to me within 20 minutes of me opening an issue, which put it way over the top of Yarn in my opinion.
One thing I keep in mind with marketing: If it doesn't come from a country where it's illegal to lie to customers, you shouldn't believe any of it. Even from a country where it's illegal, you can expect some to try and get away with it, so just never believe marketing in general.
Great point 😂. But which countries has such laws?
France
Right. Just like how no one uses drugs in countries where drugs are illegal. It's just that easy.
Yes ,thank you for your input. Maybe next time lookup numbers (on drug offenses and relevant incarcerations) beforehand. No law is, sadly, infallible. You just need to enforce it.
Once they get caught red-handed, they mostly die or try rebranding and ultimately fail.
It‘s exactly like you said. Instead of contributing to close, the potholes, people tend to reinvent the whole thing. That’s just ridiculous.
I haven't tried Bun yet, but I'm excited for it not for the reasons you're mentioning, but for:
— it supports import and commonjs interchangeably
— it renders react to javascript natively and supports typescript natively
I love the concept of being able to do stuff like this without requiring build tools.
Anyway nice post and thanks for starting an interesting discussion.
Dealing with MJS/CJS is a pain. I'm more upset that Bun made that possible and Node hasn't. If there is one feature I would love to see Node.js steal from Bun it would be allowing intermixing
requireandimport. But until Node does, it's just one more non-portable coding practice that would bite you if you wanted to move away from Bun later, so as convenient as it is, I would be far too afraid to actually use it.JSX and TypeScript are Meta-Languages, and there is a large section on that in the post. For quick convenience it is nice, but for a real long term project there are many downsides to using Bun instead of a pinned, versioned, dependency.
All good points. I wish I could code like you can write.
I like HTML and its underlying robustness principle, but clean-code advocates might disagree.
Trying to run any 2014 project on another computer wasn't easy in 2014 and it didn't improve in 2015.
That will give them something to do and keep the advertising machinery going when watchers have lost interest AI and Web3.
Like "best viewed in Internet Explorer" or Netscape back in the day. Both browsers are obsolete now.
Thanks for your post! Hopefully saved me the time to try out Bun, but we'll see.
@jared You write "once performance was prioritized, npm was able to go just as fast (faster even) than the competition" Ah, but what caused them to do that? I think we both know the answer.
Yes all this duplication of effort is sad but as long as so many open source project remain mired in dickwad governance, refusing to prioritize what actually matters to users, that will continue.
If Bun forces npm to allow first level synchronous imports and requires from and to CJS and ESM interchangeably, as it should have done 6 years ago, it is well worth any hassle. This distinction should not exist in the first place, but commitees are gonna commitee. So many hours lost with this bull load.
I really enjoyed reading your article! 😄
I am a novice and honestly after reading this and googling a lot of the terms ,i feel bun might just be another yarn ,it's circumstances around are too similar, anyway that was a very insightful blog to fledgling ( newbies.....) Devs
Just hoping that the release of Bun gets even more hyped around performance , just enough so V8 and Node teams recalibrate their priorities in the next dev cycle to quell the rebellion 😂
On the other side coding on Windows has always been a pain for most environments (web included), Microsoft knows it and against the impossibility to fix it straight away they released WSL. I know, more complexity and having to make sure you run VSCode from WSL and not from Windows is odd sometimes, plus "ew virtualization", still the best option I found so far the years I used Windows for coding which is just... use Linux instead 😅
Conclusion: It is what it is
Update 2024
Primagen did work at Netflix. Not anymore :)
Update 2024:
Primagen did work at Netflix. Not anymore :)
Hey @thejaredwilcurt you still have the old Meteor project available on a GitHub repo or something?
github.com/TheJaredWilcurt/sharibble
I took it and revived it in about 10 minutes. Would you be interested in an article about this? Since this might be interesting to other people in the Meteor.js community I would love to write about it.
FYI: dev.to/jankapunkt/reviving-an-anci...
@thejaredwilcurt will you please edit the part about Meteor? Maybe give Meteor another spin then write about it?
Actuall I first thought that it's not that big of an issue, since this about a pre-1.0 version. However, since binary is also still available and executable (due to the correct node version being shipped with it) I support @harryadel with this as the original statement is basically not true.
I appreciate your valuable insights. They have provided me with a fresh perspective. I was among the early adopters who embraced Bun as soon as version 1.0 was released, and I am actively engaged in their Discord community.
However, after a few days of working with Bun, I decided to revert to pnpm and my familiar toolset, primarily due to encountering compatibility issues. I hesitated to make extensive changes to my code for a tool that I wasn't entirely certain about keeping in my workflow.
As a side note, I used to be a Vue developer, but I have since fully committed to Svelte. I would strongly recommend giving it a try; I think it is the best thing around right now.
Also, remember what the CEO asked of employees: news.ycombinator.com/item?id=32584211 (ignore the self-gaslit comments).
Bun will never stop being a grind, and then it'll end up being for nothing as it'll stop growing enough to be faster than competition. And people will have wasted years of their lives for just that. A bit sad if you ask me.
Very insightful article. I hope people don't use Bun APIs or macros because that would split the ecosystem as you said.
I do hope they won't remake Breaking Bad, but thanks for the good read :)
Great insightful article!
You wrote about many JS technology, however the concerned problem is not only with JS, many open sourced software (libraries, frameworks, applications, OS (Linux), servers (database, web), etc.) have the same problem. Many technologies come and become obsolete just after a few years, just because new technologies come, which are not actually required, only the existing need updates. Everytime a new technology arrives, we think that now many operations have become easy, but then just to add a few missing features, a new, breaking technology arrives!
One reason behind this is, developers mostly adopt new technology because it is simpler than the existing. But later, the same technology becomes so complicated that another new simpler technology arrives, and the previous technology becomes obsolete because developers start using the new technology!
It is wasting a lot of time of developers and businesses in learning, developing, updating, testing and deploying systems.
What I have learnt is, use the core/plain main technology if you really want a long lasting project, depend on third-party technologies as less as possible.
I am hopeless for web development, and seriously thinking to move to other profession.
Great article 😁
The argument sounds like: what's wrong with our horses? why do you want to create that metal box? why not spend your energy on perfecting the horses? better breeding, better accessories and tools, for horse riding.
I am not implying that bun is to node as cars are to horses. But rather, bun, like yarn and all the other "failures" mentioned in your article, they are most likely the intermediary products between cars and horses. Why stand on the horse people side and hating on progression?
We have come a long way, all the "wasted" engineer time contributed to what we have now. I don't think there will be a vite without webpack.
Being worried about ecosystem lock-in by bun is like an Android user worrying about Apple's lock-in when they themselves were locked-in by Google. Or like: I own a Samsung TV, LG has a different remote and UI, I am not gonna switch because of that.
import fs from "node:fs"is also a "lock-in". If that's a good argument, we would still be writing assembly. Maybe for the web as well. Or is there ever going to be the web.I can agree with most of what you've said here. And honestly I haven't pictured Bun in this light, so I appreciate you took the time to share your perspective on it
That said, the problem Bun is trying to solve isn't new. Other programming languages have featured a standardized tool to build/test/deploy code for years, and this has been missing in the JS ecosystem. A good example of this is Rust's Cargo, which does the same things Bun aims to do
We'll have to wait to see how it plays out, but it's a good thing that Bun's features are optional and folks can opt in/out whenever they need to
Great article! BTW you should install Linux. It's free
Did Joe Biden write Bun? I’m confused.
Thanks for writing this, I enjoyed reading it a lot.
What is the reason you are not using WSL on Windows? For me this works great. I just had to reinstall Windows and all my dev setup was up and running after just importing the old Ubuntu WSL.
So much negative output for Bun.
You don’t like bun? No problem, it is yours, but, please, do not try to convince other people that it is bad.
Bun is a new tool and offers decent kit to streamline development and testing without much hustle.
Developers will try and time will tell if it’s good ✌️
Very interesting article thank you. When I first heard about Bun I had a similar (but less thought-out) response.
Personally I don't like swiss-army-knife-covers-all-bases libraries. And the fact that Bun is tightly-coupled to multiple specific frameworks has me seeing red flags immediately.
I'd much rather have a composable solution where you start with a very simple set of features and you can add small modules that add additional features or support specific frameworks. That way you have as fine-grained (or coarse) control over your build as necessary, and you're only coupled to tech that you explicitly want to use.
The thing is, that's what webpack and vite already do. So I'm just not sure why we need Bun at this point 👀
First of all, congratulations on the article! It's a good piece of information and brings some much needed discussions to the table of runtimes.
I think we should avoid extremisms on both sides, while I think the bun hype can be something that people are jumping on like Yarn, I also think like others have said here: "maybe if there was no Yarn, there wouldn't be the NPM we have today".
The same thing can be said for Node and JS, if there was no Node (and Node isn't the first try on JS for the server), there would be no modern JS, and we would not be having this discussion at all.
I don't think the discussion should be about "who split the environment". The thing is: competition is good, it creates innovation; period, for example, if Bun hadn't come up, 100% of the JS runtimes would use V8, which is still heavily contributed by Google. But about how the community chooses to accept that competition, or even if Bun is really the next great thing, it can be like Vue; the absolute best framework out there for a lot of people, but with a very small market share because it's overshadowed by others. Or it can become React; with a questionable line of decisions, but made industry standard. Only time will tell that.
What we can tell now is that people at Oven seem to be hardly working on making Bun good. I've met some of them, and they really believe in that, so they're doing their best.
One thing we have to remember is: while Node is a true open source project, with a governance and a whole foundation behind it, Bun (and Deno) are VC backed, which means that, eventually, they'll have to produce profits. Deno is doing that through their platform (deno.com/deploy) and I would assume that the future plan for Bun is on the same path, either creating a platform for it or offering services. Deno has done it like Vercel, Bun will eventually have to come up with something, because being a "nice fast runtime" doesn't bring money to the table.
And this is why I think the existence of Bun, Deno, and Node means absolutely nothing on the split community, Deno has been around for years, it's production ready, it's good, has good performance, but still, we don't see the same hype. Because it's not in their best interest to make Node obsolete, nor TypeScript, otherwise they would lose the same fabric that Node took 10 years to build, a base of people that love JS, and no one wants to bear the torch of being the company that will kill that in the future.
The last thing I firmly disagree is about TypeScript. I've been around the TS community for a while, I joined the community discussions with the TC39 teams regarding the stage 1 proposal of types as comments, and I can say (and you can also see that on their public notes) that this proposal won't kill or remotely affect TS at all, mostly because the majority of the syntax is being brought up from TS, but more than that; No one has ever reached a consensus in that proposal since the first meeting.
And this is important to note because, for example, we all agree that JS Date APIs really suck, there's a proposal to completely overhaul it, and still, it's been there for 5 years... On something we all agree it's bad... So types as comments, or the idea that the proposal of types will kill or make Typescript fade away is not true, in fact, it's making TS more popular.
Overall, I liked the article a lot, and will definitely revisit it in a few months or years to check those propositions, hope to read more from you in the future :D
I mean, I'm not disagreeing but a lot of this post felt like "but muh windows no workey" and thats okay, have we forgotten that windows tried to lock down development for enterprise only?. If bun is the next tool or not is not the focus IMO, its all a cycle, and tools like bun or yarn would not exist if not for all of this infighting for all this dumb abstraction which node spearheaded itself, and now we are patching node with tools and scripts for each specific need, oh and you want to bundle that typescript down to es5 before you run it on my node version! and requiring packages using 3 different import methods while also bundling declarations for typescript.
Whenever a new tool emerges, people tend to look for solutions to problems. I see that bun is yet another tool that theoretically aims to aid application development more swiftly. Whether it will be the general choice, we’ll only find out in 2026 /s.
I don't use yarn's monorepo features and it's not obvious for me why yarn is dead. We likely live in parallel universes. And what do you personally use as a package manger today? pnpm?
Most servers which npm/yarn users write software for are on Linux, so I don't get why something MUST work on Windows, for what sake?
Competition is good. If yarn wouldn't come, npm wouldn't become faster.
It's not easy to join forces in opensource. It can take years to reach a consensus. That's why people start their own projects. It's Okay.
Thanks for the article. Couple of things:
P.S.
I've observed the evolution of web techs since before jQuery existed (earliest browsers I built for were IE5 and NN v4 if not mistaken). It's a simplification but in a nutshell: there are two forces driving evolution of web technologies: natural selection and corporate endorsement. So it's all good with Bun - it will survive if competitive and die off if not. Unless it gets backed by a big player (if so then the latter force will almost certainly come in effect), but intuitively I would not bet on it.
You're just hurt because Bun doesn't support Windows
ОПА ДА КСТА НАДО БУДЕТ ПОЛТОМ ЕР МОЖЕТ ЗАВТРА
There are a lot of good and valid points in this article. Something that is missing and that I think is relevant is that as of now, the Bun team has no intention in adopting SemVer for their releases: github.com/oven-sh/bun/issues/6438
You can obviously have many arguments against SemVer, but the main issue I see here is that they just don't care about versioning at all. It is difficult to take a software project seriously if something as relevant as version numbers are just picked arbitrarily.
And yes, at the end of the day it is easy to fall for the hype, Bun is really fast, and the developer experience is great. So I think everybody would like it to succeed, but as you write in your article, the are making deep mistakes that will be difficult if not impossible to solve in the future, and if Node somehow manages to increase its performance to the same levels of Bun, then it will be game over, but I do not think this is going to be an easy feat at all...
I would like to question some statements about Yarn that are in this article.
Performance
Where do you get the performance data from? As far as I know Yarn still is faster than NPM (ofc I'm talking about yarn@3 that I'm using in repos).
Some data about it:
blog.logrocket.com/javascript-pack...
pnpm.io/benchmarks
Of course that has changed in the past, but not significantly really.
Windows issues
I think this point might be a bit exaggerated when it comes to the current situation. I was using yarn in monorepos mainly because it was working better than NPM (and ofc had monorepo support first) also on windows. My primary OS was Windows till ~2021 and I hadn't got more issues with Yarn than I had with NPM. For current state of things - one person from my team is working on Windows in Yarn 3 monorepo and it just works 🤷
Don't get me wrong - I'm not even a huge yarn fan. Currently I use pnpm in most of my repos. But for last few years I've often used yarn when monorepos were something I needed for better project organization. Yarn is not a bug-free tool, but in the end - it gets the job done (in many cases better than NPM). Especially yarn@3 with it's plugin system and workspaces commands is pretty useful.
Bun and production-readiness
With the rest of the article - I kind of agree.
But IMO the main argument should be:
Never use such immature tooling as a base of your production projects without extensive PoC phase (or detailed studies done by others).
It's true that Yarn wasn't ready to be used in big, commercial projects right after it hit stable. Neither was Angular.js, Angular (migration tooling came around much too late to the party), Vue - you name it. IMO versioning in this regard means "authors believe that the package is ready" - but, especially in OSS, production-readiness is something that needs to be confirmed by community.
I too would like to see more justification about the claim that TypeScript peaked in 2020. Looking around, I do see some evidence that TypeScript continue to grow, but remains insignificant according to the TIOBE index, for example.
The one case that seems to show a peak is css-tricks.com/the-relevance-of-ty...
TLDR
I love your story about yarn.
And I also love, and hope Bun will repeat the same thing yarn does to npm.
Big Open Source projects sometime not really welcome big change, they need a big competitive push... maybe a competitor, maybe a profit driven, or maybe just a success sample.
Thank you for writing this. It gave me a lot of new perspectives.
Just like various jvm languages that claim to be compatible and drop-in replacement of Java, they should be abandoned after completing their mission of making Java better. ;-)
Great Article really enjoyed it. Learned alot.
However, my chief concern is what new package manager was released by the time I got to the end of it?
My dude, what.
Oh look, another windows developer who doesn't know what asdf is.
logged in specifically to upvote. you're an incredible writer, keep it up
Unless you’re writing in Dot Net or MSSQL, run a proper OS like Mac or Linux, If you must run it in a docker container.
That's a really stupid take tbh, there is no "proper" OS, it's just about personal preference. Some people don't want to be bothered dual-booting Windows/Linux systems and just use Windows, because it is perhaps more convenitent for them or they need to run it for a purpose other than coding. Doesn't mean that it shouldn't be supported by new tools out of the box. Especially those who make such a fuzz about how great they are.
And what is the .NET/MSSQL jab all about? You can write and run .NET code and MSSQL on Linux/OSX as well with no problems...
sorry, but... way too long and down on everything.
is there anything going on in software that doesn't make you all moody and grumpy?
open source authors should send their projects to you before they ship, to get a true take-no-prisoners evaluation and criticism 😅
It's not entirely clear about compatibility with Windows. I wonder why you didn't mention the WSL?
WSL isn't Windows. It's Linux running in a virtual machine. From my experiences setting it up on multiple machines, it is a long and cumbersome process to get working, it isn't reliable and everyone I've known that has used it as their default terminal has had the exact same issue, where after about 2 months, out of no where, it just stops working and they need to go through the entire set up process again to get it to work. Though, thinking about it now, that does also mimic the constant level of effort required for just using Linux normally, so perhaps that is the intended experience.
None-the-less, Node is battle tested and runs on all platforms identically and the process of installing it has been a breeze for over a decade. This is also true for other tools, like Volta (Node Version Management), which is super easy to install on any OS and works identically on all of them. Also, they released their first version (0.1.0), then 8 months later they released Windows support (0.4.0). Then after 17 more months of making sure everything worked as intended everywhere and was stable, and production ready, they officially went to version 1. This is what happens when you are just focused on making a quality solution to a problem, rather than focusing on building hype to justify your continued VC funding.
To be clear, all desktop software should just run on all platforms by default. It's 2023, we have SO MANY tooling options for this now.
Solid.js anyone?
Good point about the version manager. I do not agree with the rest of it, but spot on there.
Thanks for the thoughtful write up! You hit the nail on the head, version 1.0 but it isn't compatible with 90% of machines...
One could at least argue that Yarn helped develop NPM, as in, because of the competition, NPM implemented new features that otherwise might not have been developed. Can Bun do the same?
One could also argue that all of the features Yarn added were already on npm's backlog, and that they could have contributed and helped co-develop those features on npm. An even easier argument to make (because it is true) is that forcing npm to reprioritize their backlog to focus on Yarn parity made npm stop focusing on much more valuable efforts like that of Tink, which could have really revolutionized JS package managment had it been completed. But ultimately it was abandoned after npm's top developers were all fired for trying to unionize. It turns out that npm, Inc. sucks. But ignoring the company being terrible and focusing just on the product, Yarn had a net-negative impact on package management and the JS ecosystem, though not entirely their fault.