▲ 242 points
back
134 comments
I love(?) that he absolutely predicted a global disaster between 2020-2025, he just got the wrong type. Which is very JavaScript.
He was pretty close to being NaN% correct.
Surprised no one mentioned this is the guy who brought us this masterpiece. If you haven’t seen it, drop everything and watch it, best 5 minutes of your day guaranteed.
All his talks are very good. ‘Boundaries’ is probably the most illuminating video I have ever seen on software architecture, its lessons I still think about when I design any complex application.
Incidentally it’s also a great introduction to thinking as a functional programmer if you are used to imperative logic with state spread all over the place.
There are a few mistakes in this talk; I'll list just two that I noticed.
1. He calls Array(16) and then talks about there being 16 separators. Of course, there are only 15. This kinda breaks the Batman joke.
2. He writes {}+[] and claims that he's adding a list to an object, then mocks the fact that it gives a different result than []+{} which gives [object Object]. In reality, if you write ({}+[]), you also get [object Object]. I'll leave it as a puzzle for you to figure out why {}+[] is different. (Hint: Gurer vf ab bowrpg gurer.)
Amazing, thanks!
That's actually fantastic.
amazing
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.
> 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.
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.
> 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.
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.
> 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.
> 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.
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.
> 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.
> asm.js (that's been deprecated, hasn't it?)
https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-a...
iirc, v8 never had any special compilation path for it to begin with.
> the fastest way to support Mac, Windows, and Linux all at once
Tcl with TK or Free Pascal on Lazarus
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.”
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++.
> 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
> 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.
> 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
Every few years, we invent a better JavaScript. Then we transpile it to JavaScript.
Mass adoption trumps good design every time.
It's all assembly code in the end. There's nothing intrinsically wrong with compiling down to Javascript, a high-level language can still implement many things that direct Javascript does not. Just about every language guarantee you've ever used can be violated by raw assembler.
The problem is Wasm is not improving nearly as fast as predicted here. We don't have DOM manipulation so we will still need JS regardless as glue code, or just eschew HTML and CSS altogether and render everything on a canvas as Flutter and some Rust GUIs do but that's a shame to lose the feature set of the web.
People choosing Flutter would say the uniformity of a canvas across all browsers is more valuable than gaining the inconsistently implemented web feature set.
JS is just so much more approachable than WASM. You can debug it on the fly, feed it to an LLM, there is no wrapper, it's just so much easier to tinker and work with it.
The DOM and JS are joined at the hip - the DOM APIs are designed assuming JS is used to access them, and the design of JS and some of its more “unique” features is partly because it was designed for use with the DOM
I remember watching Gary Bernhardt give this talk live at the Canadian Undergraduate Software Engineering Conference (CUSEC) back in 2014. PNaCl had just come out the year prior, and Google was using it to cross-compile, run, and sandbox OpenSSH and RDP clients inside of Chrome and ChromeOS, and the Mozilla/Firefox folks counter-proposed asm.js as a response.
At the time I just thought it was funny. Now I find it surprising how much of these ideas ended up sticking around.
Gary Bernhardt's Wat lightning talk [1] was my favorite of all time.
It's only 2 years predates this talk in the title.
Almost everything happened according to the script. Now we are just waiting for another OS fully based on browser technology or WASM OS.
webOS and Firefox OS was at least 20 years ahead of its time.
Not at all. WASM is a repudiation of the thesis, not a confirmation.
The thesis is that javascript-compatible source will be the substrate of the future. A javascript engine, though one highly optimized to efficiently interpret a compatible subset, is a potential universal platform of the future despite generic javascript being a terrible substrate.
WASM fundamentally rejects this by creating a new javascript-incompatible substrate that is actually designed to be a low level target. Claiming WASM is confirmation of the thesis makes as much sense as claiming that a future where everybody has a Rust interpreter in the browser is confirmation of the thesis.
If you are arguing that, then you are just arguing that web browsers will run code in some form in some language as they already do. As the video is clearly discussing a “surprising” possible future, it makes little sense for it to be consistent with literally business as usual and literally every possible future.
Is there a technical reason you don't mention ChromeOS?
Just asking out of curiosity.
Also, the screenshots I've seen of webOS makes me long for a revival... not only on smart TVs
Regardless of the content, this is one of my most favourite talks ever, especially in the delivery aspect. It served me as an inspiration for quite some time when I had to present anything to a wide audience.
We’re past the halfway point of Bernhardt’s 2035 timeline; JavaScript hasn’t died yet, but it’s clearly writing its own eulogy in WebAssembly.
"YavaScript" made me smile.
I think JS, is yet to rise the agents, and using all the next.js components.
I skim though it and saw they had something javascript asm.js in kernel.
Great talk. I'm glad he was wrong about this. Having js/wasm be the standard ABI would have been horrible. Obviously he could have never predicted in 2014 that Valve would pour a metric fuckton of resources into improving Wine/Proton, to the point of getting x64 binaries to run on other architectures. But here we are, past the year of the Linux desktop, well on our way to the year of the Linux handset.
JavaScript is the greatest programming language of all time.
I was actually expecting, typescript takeover.
interpreted languages carry a lot more context than compiled ones. Sandboxed compiled languages don’t have the context baggage, but come with other parts of the brain dead.
My first contact with js was trying to make a button change its color on mouseover. There was no css back then. I bought a book and was so put off from the syntax that i never looked back to js from that day on. Never regretted my decision