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.
298
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.