The Birth and Death of JavaScript (2014)(destroyallsoftware.com) |
The Birth and Death of JavaScript (2014)(destroyallsoftware.com) |
The 'death' being discussed here means that JavaScript becomes the substrate, a state where you don't use it directly, but it's everywhere. And that has truly come to pass.
Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo.
That said, idk how the performance compares to Electron or Native apps.
As a small team, optimizing for "actually getting the thing shipped" is so much better than optimizing for speed anyway.
Hopefully the desktop story is going improve as Canonical is now leading the Flutter desktop side.
Flutter is a joke on the web, and it consumes as much as Electron, sometimes worse, on a desktop.
Performance is very fast as it's all natively AOT compiled machine code without any web views like Electron.
The benefit of JavaScript is, that, after Google really pushed it to its limit with V8 and of course NodeJS made it a backend dream, that it is ubiquitous and once written usable everywhere, much kinda like PDF.
Its versatility gave it the advantage over WebAssembly to this day, because it is not as widespread available as JavaScript.
I agree with you, that JavaScript itself is nowadays tantamount with TypeScript - what a giant leap this has been. Angular (2) was the unsung hero here. Angular was harshly criticized when they went TypeScript right from the beginning while still offering a native JavaScript version as well (which was basically unusable to be honest).
It is funny, that the last hideout not featuring TS as their default option is React, while more and more major integral projects like NextJS rely out of the box on TS. ReactJS will fall, too. It wouldn't be the first time regarding innovations coming from other projects. Again Angular is leading the innovation while ReactJS is a follower.
You rarely can go wrong with JavaScript and Python, I would say.
This is a pedantic point, but that's not really what the definition of compiler is as much as a common understanding of it. By definition, it just translates one language into another, and a human-readable to human-readable translation is still a compiler ("transpiler" is more slang than actual formal terminology).
This might just be one of those already lost battles, but like "crypto" being used to mean "digital money" rather than "cryptography", I feel like the new terminology is weird and unnecessary, so it's something I have trouble adapting to even though I rationally know that usage evolves over time and sometimes the words I like less will become the norm.
I also agree with your opinion on Angular.
But I like React, so I'm a little sad. Still, I mostly agree with you.
The reasons you criticize React are exactly the reasons I love React. Because it changes slowly, even someone like me can keep up. (Just kidding.)
Not sure what timeline you’re living in, but people absolutely still write tons of JS, and WebAssembly has yet to take over as a commonly used runtime for web applications. You can definitely find examples of companies building on it, but don’t mistake that for the kind of sea change Gary was describing here.
https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-a...
iirc, v8 never had any special compilation path for it to begin with.
I am hesitant to call that "support". If even Meta can't get their Electron application to work reliably, who can? WhatsApp client for macOS is awful and it's getting worse. Discord is awful and it's getting worse. Spotify works better when running through the browser. At this point, when I see that the application is using Electron, I am assuming it's not supported on my OS and I move on.
Websites have actually long been a great cross-platform mechanism
Just a shame about the giant browser you have to load first
But even document rendering with light scripting is not trivial so yeah, the required browser is the bottleneck.
I always wonder (layman question): couldn't native Electron apps (and similar technologies) save a great deal of RAM by using the same sandboxing model for apps that browsers use for tabs, instead of fully-fledged instances?
Was that an idea that Tauri also tries to implement, or am I remembering this wrongly?
There were two buttons, one labeled "Our Web Site", the other labeled "Our Competitor's Web Site".
When you moved the mouse over the "Our Competitor's Web Site" button, it would quickly slide out from under your cursor before you could click it!
Then when you stopped moving your mouse, the "Our Web Site" button would slyly slide right underneath your mouse!
Dammit Microsoft!!! ;)
And now with typescript and running it in the server... I'd rather just use Java.
js is mutant C with dementia - hacked together over over a fortnight, full of inconsistencies and weird corners.
console.log(1 + "2"); // "12"
console.log(1 - "2"); // -1
console.log(NaN === NaN); // false
console.log(+0 === -0); // true
const obj = {};
console.log(obj.foo); // undefined, not an errorIt's like PHP, it will never die.
I predict that PHP will live a long life, but not as long as C, and I predict JavaScript will have a lifespan closer to C's than PHP's.
> This is a pedantic point, but that's not really what the definition of compiler is as much as a common understanding of it. By definition, it just translates one language into another
The history and etymology doesn't support that definition, either; that's just another "common [mis]understanding" of the term. It's in the name. A compiler produces a compilation—an aggregate of multiple subroutines, including user-supplied ones and some by the system/programming environment, transformed into a single program for a given target.
(You're describing the process of "autocoding", a job that every compiler does, and a term that predates "transpiler" but that no one uses because they favor stretching the more frequently encountered term "compiler" for their use case.)
I'm not sure if the web render engine has gotten better since then, and am too lazy to look up the links rn, but threads should be easy to find using HN search.
Still seems like a common source language + GUI toolkit that targets the web platform and various native platforms (mainly Android, iOS, macOS, Windows, and desktop Linux of course) without significant overhead has not been achieved yet. And it's questionable whether it's possible, given the special requirements (and capabilities) of the web platform and the different native platform.
For Flutter web, yes as it's canvas based it doesn't have all the same web features but generally for crud apps it doesn't much matter, especially if it's near zero effort taking your Flutter mobile and desktop app and putting it on the web. With the new impeller renderer and Wasm improvements it has gotten quite faster too.