The Birth and Death of JavaScript (2014)

146

ssubset about 4 hours ago 77 commentsRead Article on destroyallsoftware.com

DE version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

78% Positive

Analyzed from 2345 words in the discussion.

Discussion (77 Comments)Read Original on HackerNews

DavidPiper•about 4 hours ago

I love(?) that he absolutely predicted a global disaster between 2020-2025, he just got the wrong type. Which is very JavaScript.

noman-land•about 2 hours ago

He was pretty close to being NaN% correct.

moritzwarhier•about 1 hour ago

To be fair there were a couple of disasters, such as [object Array] and undefined.

Feels like the world is hanging on a single thread by now.

jdw64•about 4 hours 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.

frail_figure•about 3 hours 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.

derfurth•about 3 hours ago

In my experience performance is about the same as native on mobile. On desktop I cannot compare as I thankfully never had to make cross platform desktop apps using native platform SDKs, but Flutter is doing fine. I am a working on a non trivial desktop app, and I am pretty happy about it.

Hopefully the desktop story is going improve as Canonical is now leading the Flutter desktop side.

wiseowise•about 3 hours 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•about 3 hours ago

You got sources to back this up, or is this just you're opinion?

satvikpendem•about 2 hours ago

Where does it consume more than Electron?

vips7L•about 2 hours ago

Darts an amazing language too.

pjmlp•8 minutes ago

It is basically a revamped Java.

Google lost the opportunity to actually make it take off, had they replaced the Java stack with Dart, instead of staying in the Java world and adopt Kotlin.

However the Android team was never a great supporter from Dart in first place, hence why you won't find anything Dart on https://developer.android.com.

satvikpendem•about 2 hours ago

Flutter is great, still the fastest way to make cross platform mobile apps and you get desktop and web support essentially for free.

Performance is very fast as it's all natively AOT compiled machine code without any web views like Electron.

greekrich92•about 1 hour ago

On desktop does flutter have native access to the machine it's running on? Can it talk to printers for example?

_the_inflator•about 3 hours 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.

saghm•about 3 hours 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•about 2 hours 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•7 minutes ago

> You rarely can go wrong with JavaScript and Python, I would say.

Depends on how much you care about your user's computers.

jdw64•about 3 hours 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.)

Dwedit•about 2 hours 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.

wffurr•about 2 hours ago

The WebAssembly component people are pushing Wasm as a replacement for container-based virtualization, so it's not that far off.

jdw64•about 2 hours 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

Uehreka•about 2 hours 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.

satvikpendem•about 2 hours 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•about 1 hour 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.

bee_rider•about 2 hours 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.”

krautsauer•about 3 hours ago

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

wffurr•about 2 hours ago

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

neonstatic•about 2 hours 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.

lelandfe•about 3 hours 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•about 3 hours 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•about 2 hours 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.

eranation•about 2 hours ago

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.

https://www.destroyallsoftware.com/talks/wat

nosioptar•26 minutes ago

That's actually fantastic.

satvikpendem•about 2 hours ago

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.

Zigurd•about 2 hours ago

People choosing Flutter would say the uniformity of a canvas across all browsers is more valuable than gaining the inconsistently implemented web feature set.

satvikpendem•37 minutes ago

Yes that's probably true.

jansan•8 minutes ago

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.

oakinnagbe•about 4 hours ago

Every few years, we invent a better JavaScript. Then we transpile it to JavaScript.

notarobot123•about 3 hours ago

Mass adoption trumps good design every time.

jerf•about 3 hours ago

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.

ksec•about 1 hour ago

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.

Veserv•3 minutes ago

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.

moritzwarhier•44 minutes ago

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

frollogaston•33 minutes ago

Not the parent, but: ChromeOS isn't what I'd call a web-based OS. It supports Android apps, and that's how you get a lot of things that don't have web versions. Not much different from how Ubuntu can run Chrome and also supports native apps.

moritzwarhier•29 minutes ago

Good point. Since I've never owned a Chromebook, I didn't even know that they are capable of installing arbitrary Android apps.

nosioptar•12 minutes ago

Personally, I dont consider chromeos wheb thinking about operating systems because it's not a real os, its a toy released by a shady advertising company. (Same as android.)

checkthisgot•about 1 hour ago

I think JS, is yet to rise the agents, and using all the next.js components.

Surac•about 4 hours ago

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

satvikpendem•about 2 hours ago

I find these sorts of comments quite strange. So one tried something over 30 years ago and was put off by syntax of all things and then decided they'd never look at it again? So weird to base opinions on 30 year old experiences that were not even in-depth experiences but cursory glances.

notesinthefield•about 4 hours ago

I had a similar path and never came back to JS until work forced me to learn. To me, it has only gotten more readable.

julianlam•about 4 hours ago

s/JS/PHP

afavour•about 2 hours ago

There are a ton of reasons to object to JS but the syntax? It isn’t even all that unique.

comrade1234•about 3 hours ago

I kind of like real JavaScript with prototype inheritance. It's not how we use it in browsers though.

And now with typescript and running it in the server... I'd rather just use Java.

falcor84•about 3 hours ago

The syntax? I got 99 problems with js, but syntax ain't one of them. It's just C-style syntax, no?

TheOtherHobbes•about 2 hours ago

C syntax was never that great. It's basically mnemonic PDP-11 assembler with a few added data structures.

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 error

bryanrasmussen•about 1 hour ago

NaN is a standardized dynamic languages datatype governed by IEEE 754, this is not something to complain about as its behavior is part of the official standard and for good reason, as outlined in the standard.

DonHopkins•about 1 hour ago

Reminds me of one of Microsoft's first Dynamic HTML demos:

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!!! ;)

RIshabh235•about 4 hours ago

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.

wiseowise•about 3 hours ago

Multiple generations of your family will be long dead before last JS instruction gets executed. Unless there's going to happen a global thermonuclear war. I still bet on JS surviving over most humans.

jazz9k•about 4 hours ago

I review many sites/month from different clients. They are all using some form of JavaScript.

It's like PHP, it will never die.

matt_kantor•about 3 hours ago

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

jerf•about 3 hours ago

"Death" is hard to define for a programming language. It's tempting to say "the last time anyone writes it", or maybe "runs it", but to put that in biological terms that seems like defining "death" for a person as "the last chemical bond that was part of their body is broken"... sure, it'll happen someday, but all the properties we associate with the term "death" happen rather soon than that.

varun_ch•about 3 hours ago

It’s also relevant that LLMs have so much JavaScript training data that I don’t see a world where we’re not still using JavaScript.

fishfasell•about 4 hours ago

The JS death and AI bubble are two events I keep hearing about but will never come.

inigyou•about 3 hours ago

The AI bubble is now, maybe you mean the AI bubble pop

j16sdiz•about 3 hours ago

I skim though it and saw they had something javascript asm.js in kernel.

marking-time•about 3 hours ago

"YavaScript" made me smile.

arkadiytehgraet•about 3 hours ago

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.

jhatemyjob•39 minutes ago

Same. I think I watched this 10 times when it first came out.

jhatemyjob•38 minutes ago

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.

naveen99•about 3 hours ago

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.

Dwedit•about 2 hours ago

I don't think Javascript is still interpreted though?

DonHopkins•about 1 hour ago

Let's just say it's open to interpretation.