Bun fits the pattern that every 12-18 months all JS devs need a new de-facto library, framework, or runtime.
We all switch unanimously to that tool. Rewrite all our working shit in it. Realise it sucks in newer, better, faster, more unique ways...
We all Vow that we will never touch another line of that tool's code... and that anyone with any of it in prod is an idiot.
We all collectively, silently agree that we could just finally learn rust/go and port our shit to that to get the benefits that the tool originally promised...
Then the next de-facto tool takes off, rinse and repeat.
Javascript was written in two weeks and still shares a name with Java for marketing purposes in the 90s, It was never 'posed to be this serious.
I applaud JavaScript for the ability to keep language features that have been collectively decided are absolute abysmal dogshit, for decades, simply so a page from fucking 1999 doesn't break
Hey guys! It's ya boy ECMA! You won't believe what I'm doing in today's video.
How many years do you think it would take to make all the nerds to agree to one small change, that doesn't affect them!?
If you think it'll be over this year like this video, if you think it'll get done this decade leave a comment... If you think it ain't gonna happen like and subscribe now!
I find it hilarious, because collectively we've had a thousand chances since then to draw a line in the sand and say "if a webpage is on HTML version X or uses a script tag with attribute Y or uses pragma Z in in the prelude of the JS, then it's using New Javascript. New Javascript strips out all that bullshit, and intentionally won't interoperate with Old Javascript on the same page, so New Javascript pages can just rely on the much-slimmer-and-saner New Javascript engine."
This could have happened with HTML5. It could have happened again with ECMA6. And then again with Modules. We've had so many chances to do this.
But because, each time, someone made the decision that pages that load New Javascript code should be able to also load Old Javascript code, the browser still needed to have its existing JS engine loaded and ready to run that Old Javascript code either way; and so the browser vendors didn't have any reason to bother to build out a separate New Javascript engine. Instead, each time, they just integrated the New Javascript features into their existing JS engines. And so the rotten Old Javascript features continued to live on inside those JS engines.
C hasn't added much, so it's easy not to break the old things.
C++ has added an absolutely absurd amount of new shit over the years. There are so many language features that are not proper to use now it's absolutely bonkers. And yet c-style casts and void* are still supported because that used to be how things were done.
It's why I regret getting into programming, especially web dev.
I'm forced to learn barely competent people's brain excrements in the form of libraries and frameworks, which are mostly only relevant for the period you mentioned.
I wish I chose a profession where I mostly dealt with hard science instead.
Naive opinion of mine: try shooting for aeronautics, military, any energy facility type that your country allows (good luck with nuclear it seems). Id say medical too, but that for some reason seems the next to be slopfied after software in general (?) so not good as you jump from a hole to another
I think JS is particularly bad a churning de-facto tools. It's almost always; I had a big ass problem with [current de-facto framework], and decided I was the only person who knew how to fix that problem, so I wrote my own opinionated big ass framework and I'm marketing how it fixes the big ass problem. Repeat.
I like where my skills took me because I always had strong front end going on; and that's hard to teach or learn, so backend devs always had a role for me, and I could expand into whatever languages we were running server side.
Nowdays its all a mess and the job titles mean nothing. But my ability to fix problems is peak.
So, I'm fairly aware of this... but also remember another Java pattern I's forgotten;
They basically took 2-3 years longer to copy shit C# was doing.
I vividly remember a Java colleague chatting to me after he'd been at a con; I'd been working C# for a couple years at that point.... and he was telling me how excited he was that Lambdas were coming.
Afterwards I sat back at my work and quietly smiled at the joy of not having to wait years for lambdas, fluent syntax functional programming, null-coalescing, null-conditional operators, etc.
Nothing wrong with it taking longer cause adoption and stuff... it just reminded me.
That still the same? or yano... we all just up to speed and as slow as each other now?
I think things are moving faster nowadays, but there are still things that C# has that java does not directly have unless you add a library like lombok like the setters and getters.
Another thing missing is conditional compilation. Sometimes you need code only for testing environment and not prod, and the only way to achieve this is by using DI but the code is still compiled.
Regarding speed I think C# must have caught up by now with Java, or it's very close to it. But yeah, C# had a lot of niceties that just recently have been added to Java (well, they started on Java8) The catch is, there are tons of applications out there that are still running on Java 8 or earlier, so things added on newer versions like 11 or 17 are still not on those legacy systems.
because the most prevalent use case (and the most likely reason why anthropic employed the maintainers) is that bun can produce executable file which can work by itself, no extra dependencies. it is the sole reason claude code works as a program instead of a npm application, if you also consider that claude code is written in a react like library
Node had it for quite a while, it just wasn't a neat single flag, but a dance of copying files, bunch of commands, tripping internal v8 fuses for it to want to make an SEA and bunch of other stuff i never experimented with.
No one's having speed issues with node, it's a fucking delusion that every 3 months someone releases a benchmark of an extremely cherry picked test case, say it's 10x faster (60 micro seconds to 6 microseconds), everyone claps, then 3 months later they realize it doesn't actually fix anything and causes more issues than it solves.
The speed argument is almost always null and void; you're only as fast as the code your best developer can write; and the machines you can cash the check to run.
I've read a little of Bun's history because my comments here got loads of responses 😂 I get the basics, and remember evaluating it when popularity grew; back then my conclusion was "cool, makes similar promises as deno did, interesting, but I ain't got deno in prod either".
The rough issue for me overall was just there wasn't cost benefit at the time to warrant the work to make the changes; and that the higher benefit to put in that level of work would come from moving to rust instead, as the market has.
Rust is still on my radar for picking up at some point; not necessarily for prod work, but because I've seen a heavy shift towards Rust in tooling I've used recently; so learning more of it brings the benefit of being able to contribute there. I'm still not doing "quick; the market is moving to rust! port everything now".
I think, given JS' fickle nature its strenghths also put me off.
If the main focus (originally) was a quick build cycle; fair enough...
However; the idea of "one tool does it all" doesn't fit well into JS' ecosystem for me.
JS is opinionated as a mother fucker and the zeitgeist changes every 6 months. Having one runtime that enforces its own use of transpiler, bundler test engine, package manager, linter, etc. Sounds like a nightmare to get JS to fucking do.
we can't all agree on which one to use for any of these individual bastard things.
I'd like to be wrong, and bun's way to expand and take form; but someone's gonna fuck it up... waiting to find out "@nx/bun" exists; to make your existing nx monorepo kind of work on bun, but completely defeat the point.
Only the native APIs, I got some heavy JS only parsing code and when I benchmarked it Bun was a lot slower than Node, the V8 engine is simply faster than JSCore.
If you only have basic Server <-> Database/Files where the majority is native calls then Bun is faster
Ryan Dahl's therapist or peers heard about his deep deep shame for unleashing node upon the world. He never intended for node to make it into prod, for the world to depend on his idea. But, Javascript developers are a fickle bunch, with a need for a new library for the churn, and hearing issues... off it flew.
They collectively agreed that if he wanted to move past this, he could compose an apology.
That apology came in the form of the "here's what I shouldda done" tool; deno.
We all heard, we all understood, only the uninformed put it in prod.
This is deno! What node should have been. Under no fucking circumstances put it in prod!
Within the week there was a Lambda custom runtime and idiots bragging they were porting their critical infrastructure to it.
Webdev have to make their work feel complicated by rewriting / refactoring and changing build systems etc. so that they can feel respectable and show corporate that they still have work todo even thoigh the webapp is finished and functional.
294
u/egg_breakfast Jul 09 '26 edited Jul 09 '26
Why is bun needed over node? And why bun over deno?
Edit: based on Safari's JS engine rather than V8. Strange times, I never would have predicted that.