5 ms·

JS became a compilation target (and it really did), and back then in the video it was asm.js (that's been deprecated, hasn't it?), but then WebAssembly came alo

by jdw64 5mo ago

JS became a compilation target (and it really did), and back then in the video it was asm.js (that's been deprecated, hasn't it?), but then WebAssembly came along... Seeing it actually being implemented and running natively, it seems his prediction was accurate. I mainly use TypeScript myself, and now with Electron, web technologies are wrapped into desktop apps, so web syntax has even entered computer programs. People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once. Sometimes insights like that are surprising. 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.

_the_inflator 5mo ago
JavaScript is the new assembler layer so to say. Every compiler as per definition translates human readable code into machine language. 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.
- jdw64 5mo ago
  You seem to have said what I was trying to say, but much more eloquently. 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.)
- saghm 5mo ago
  > Every compiler as per definition translates human readable code into machine language. 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.
  - cxr 5mo ago
    It's no use being pedantic if you're not going to be correct. > 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.)
- pjmlp 5mo ago
  > You rarely can go wrong with JavaScript and Python, I would say. Depends on how much you care about your user's computers.
- eikenberry 5mo ago
  > course NodeJS made it a backend dream More a nightmare than a dream. It lead to the terrible practice of tightly coupling frontend and backend code bases that led to inevitable pain. The language barrier between front/back-ends was a key aspect of web-dev that allowed it to a foothold vs. previous, unsuccessful attempts. Fortunately this practice hasn't taken over and sane architectures are still prevalent.
frail_figure 5mo ago
> but it's also the fastest way to support Mac, Windows, and Linux all at once. 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.
- wiseowise 5mo ago
  > Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo. Flutter is a joke on the web, and it consumes as much as Electron, sometimes worse, on a desktop.
  - ifh-hn 5mo ago
    You got sources to back this up, or is this just you're opinion?
    - moritzwarhier 5mo ago
      Regarding the "joke on the web", there's plenty of HN threads about Flutter where you will see this sentiment, not only about performance, also about UX (e.g. text rendering, selection, scrolling...). 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.
      - satvikpendem 5mo ago
        Dioxus Native supports both web and native platforms because they serve HTML and CSS for the web and then on native they turn that into canvas rendered code just like Flutter, not a webview, because they built their own HTML and CSS renderer. 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.
krautsauer 5mo ago
> asm.js (that's been deprecated, hasn't it?) https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjs.html https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-a... iirc, v8 never had any special compilation path for it to begin with.
- wffurr 5mo ago
  V8 also supported AOT for asmjs but it's since been removed as well.
lelandfe 5mo ago
> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once Websites have actually long been a great cross-platform mechanism Just a shame about the giant browser you have to load first
- moritzwarhier 5mo ago
  To be fair, implementing something like the Spotify client does require a web app, not "just" a web site. 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?
  - ymolodtsov 5mo ago
    It'd be great if Electron itself became a core part of the OS. Tauri is closer to this on MacOS because it tries to use WebKit but not enough.
Dwedit 5mo ago
Within the video's story, they removed virtual memory and memory protection because the JIT was good enough. Nothing like that has happened at all.
- jdw64 5mo ago
  Sometimes I think, I wish I had the knowledge to dig into these kinds of detailed parts like you do. I tend to obsess only over the context of what the video is trying to say, so I miss these small details. You probably achieved that through hard study. I looked it up, and you were definitely right
- wffurr 5mo ago
  The WebAssembly component people are pushing Wasm as a replacement for container-based virtualization, so it's not that far off.
neonstatic 5mo ago
> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once 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.
Uehreka 5mo ago
> 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. 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.
bee_rider 5mo ago
I wonder, has did anyone try a hardware accelerator for web assembly? Cursory googling, I found a research paper, but from 2024, so maybe too recent to be a “real thing.”
satvikpendem 5mo ago
As someone else said, Flutter is good, but also look into Rust based GUI development. With frameworks like GPUI or Slint or egui, they are optimized for cross-platform desktop use cases specifically and are significantly faster and more lightweight than Electron and these days do also support macOS, Windows, and Linux out of the box.
krzyk 5mo ago
> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once. But why make an app when websites is enough? And I don't need to run n web browsers for that.
veqq 5mo ago
> the fastest way to support Mac, Windows, and Linux all at once Tcl with TK or Free Pascal on Lazarus
- winrid 5mo ago
  Python with TK at least gives you a type system and same cross platform support...
dnautics 5mo ago
> it seems his prediction was accurate Not really. his two predictions are 1) that EVERYTHING will be running on some javascript assembler. We are getting incrementally closer with things like firecracker, but plenty of stuff still runs on bare metal, and it doesn't seem like it's going away so easily. 2) that no one will write javascript anymore. I don't think typescript is different enough to count.
alerighi 5mo ago
> but it's also the fastest way to support Mac, Windows, and Linux all at once Is really that simple compared to a normal cross platform web application written in (for example, but there are multiple frameworks) QT? I mean, sure you have to write JavaScript and not C++, but in the end is that more simple? Maybe to start with yes, but then you get into tooling, typescript, multiple build steps, etc that makes it probably more complex than a old boring QT program in C++. And nowadays with most software not even written by humans, does the argument "but javascript is simpler than C++" really holds? It's absurd than we could have very performant computers, and we still have the performance of 10 years ago because the added resources in modern PCs gets wasted by programs that need to run an entire Chrome instance to do basic stuff. I mean, open 4 programs that use Electron (Discord, Spotify, VSCode, WhatsApp desktop) on a modern PC and you consumed most of the available RAM just for them.
- jdw64 5mo ago
  You're not wrong, but users' UI/UX experience is already aligned with web apps. QT is weak on the web side, and with C++, there are too many things to worry about. Precisely because I don't write it directly, I think what I need is not C++ but JavaScript. Thread safety and verification responsibilities in C++ are, in my opinion, the biggest bottlenecks in the age of AI development. I'm tolerant of the brief pauses caused by JavaScript's garbage collector, but users are not tolerant of crashes. That's the key. And while the core engine should be in Rust or C++, the code presented to the user? Yes, I think Electron is the right choice. The reason is that it's a familiar UI. If you present an unfamiliar new UI, users have to relearn it. But web UI is already familiar to most generations. From this perspective, I think Electron is far better than C++ in terms of design. I don't believe performance always wins.
throwaway_95283 5mo ago
haven't web browsers always been C/C++? they are typescript now? it would seem the fastest way to support Mac, Windows and Linux is 500MB of C++.
mpweiher 5mo ago
> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once. Let's fix that! ASMOP

by jdw64 5mo ago

_the_inflator 5mo ago

JavaScript is the new assembler layer so to say. Every compiler as per definition translates human readable code into machine language. 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.

jdw64 5mo ago
You seem to have said what I was trying to say, but much more eloquently. 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.)
saghm 5mo ago
> Every compiler as per definition translates human readable code into machine language. 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.
- cxr 5mo ago
  It's no use being pedantic if you're not going to be correct. > 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.)
pjmlp 5mo ago
> You rarely can go wrong with JavaScript and Python, I would say. Depends on how much you care about your user's computers.
eikenberry 5mo ago
> course NodeJS made it a backend dream More a nightmare than a dream. It lead to the terrible practice of tightly coupling frontend and backend code bases that led to inevitable pain. The language barrier between front/back-ends was a key aspect of web-dev that allowed it to a foothold vs. previous, unsuccessful attempts. Fortunately this practice hasn't taken over and sane architectures are still prevalent.

frail_figure 5mo ago

> but it's also the fastest way to support Mac, Windows, and Linux all at once. 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.

wiseowise 5mo ago
> Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo. Flutter is a joke on the web, and it consumes as much as Electron, sometimes worse, on a desktop.
- ifh-hn 5mo ago
  You got sources to back this up, or is this just you're opinion?
  - moritzwarhier 5mo ago
    Regarding the "joke on the web", there's plenty of HN threads about Flutter where you will see this sentiment, not only about performance, also about UX (e.g. text rendering, selection, scrolling...). 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.
    - satvikpendem 5mo ago
      Dioxus Native supports both web and native platforms because they serve HTML and CSS for the web and then on native they turn that into canvas rendered code just like Flutter, not a webview, because they built their own HTML and CSS renderer. 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.

krautsauer 5mo ago

> asm.js (that's been deprecated, hasn't it?) https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjs.html https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-a... iirc, v8 never had any special compilation path for it to begin with.

wffurr 5mo ago
V8 also supported AOT for asmjs but it's since been removed as well.

lelandfe 5mo ago

> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once Websites have actually long been a great cross-platform mechanism Just a shame about the giant browser you have to load first

moritzwarhier 5mo ago
To be fair, implementing something like the Spotify client does require a web app, not "just" a web site. 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?
- ymolodtsov 5mo ago
  It'd be great if Electron itself became a core part of the OS. Tauri is closer to this on MacOS because it tries to use WebKit but not enough.

Dwedit 5mo ago

Within the video's story, they removed virtual memory and memory protection because the JIT was good enough. Nothing like that has happened at all.

jdw64 5mo ago
Sometimes I think, I wish I had the knowledge to dig into these kinds of detailed parts like you do. I tend to obsess only over the context of what the video is trying to say, so I miss these small details. You probably achieved that through hard study. I looked it up, and you were definitely right
wffurr 5mo ago
The WebAssembly component people are pushing Wasm as a replacement for container-based virtualization, so it's not that far off.

neonstatic 5mo ago

> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once 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.

Uehreka 5mo ago

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

bee_rider 5mo ago

I wonder, has did anyone try a hardware accelerator for web assembly? Cursory googling, I found a research paper, but from 2024, so maybe too recent to be a “real thing.”

satvikpendem 5mo ago

As someone else said, Flutter is good, but also look into Rust based GUI development. With frameworks like GPUI or Slint or egui, they are optimized for cross-platform desktop use cases specifically and are significantly faster and more lightweight than Electron and these days do also support macOS, Windows, and Linux out of the box.

krzyk 5mo ago

> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once. But why make an app when websites is enough? And I don't need to run n web browsers for that.

veqq 5mo ago

> the fastest way to support Mac, Windows, and Linux all at once Tcl with TK or Free Pascal on Lazarus

winrid 5mo ago
Python with TK at least gives you a type system and same cross platform support...

dnautics 5mo ago

> it seems his prediction was accurate Not really. his two predictions are 1) that EVERYTHING will be running on some javascript assembler. We are getting incrementally closer with things like firecracker, but plenty of stuff still runs on bare metal, and it doesn't seem like it's going away so easily. 2) that no one will write javascript anymore. I don't think typescript is different enough to count.

alerighi 5mo ago

> but it's also the fastest way to support Mac, Windows, and Linux all at once Is really that simple compared to a normal cross platform web application written in (for example, but there are multiple frameworks) QT? I mean, sure you have to write JavaScript and not C++, but in the end is that more simple? Maybe to start with yes, but then you get into tooling, typescript, multiple build steps, etc that makes it probably more complex than a old boring QT program in C++. And nowadays with most software not even written by humans, does the argument "but javascript is simpler than C++" really holds? It's absurd than we could have very performant computers, and we still have the performance of 10 years ago because the added resources in modern PCs gets wasted by programs that need to run an entire Chrome instance to do basic stuff. I mean, open 4 programs that use Electron (Discord, Spotify, VSCode, WhatsApp desktop) on a modern PC and you consumed most of the available RAM just for them.

jdw64 5mo ago
You're not wrong, but users' UI/UX experience is already aligned with web apps. QT is weak on the web side, and with C++, there are too many things to worry about. Precisely because I don't write it directly, I think what I need is not C++ but JavaScript. Thread safety and verification responsibilities in C++ are, in my opinion, the biggest bottlenecks in the age of AI development. I'm tolerant of the brief pauses caused by JavaScript's garbage collector, but users are not tolerant of crashes. That's the key. And while the core engine should be in Rust or C++, the code presented to the user? Yes, I think Electron is the right choice. The reason is that it's a familiar UI. If you present an unfamiliar new UI, users have to relearn it. But web UI is already familiar to most generations. From this perspective, I think Electron is far better than C++ in terms of design. I don't believe performance always wins.

throwaway_95283 5mo ago

haven't web browsers always been C/C++? they are typescript now? it would seem the fastest way to support Mac, Windows and Linux is 500MB of C++.

mpweiher 5mo ago

> People say Electron is heavy and not great, but it's also the fastest way to support Mac, Windows, and Linux all at once. Let's fix that! ASMOP