The Birth and Death of JavaScript (2014)

75 pointsposted 2 hours ago
by subset
(destroyallsoftware.com)

34 Comments

jdw64

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

Dwedit

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

frail_figure

42 minutes 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

17 minutes 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

32 minutes 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

22 minutes ago

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

moritzwarhier

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

_the_inflator

an hour 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

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

jdw64

42 minutes 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.)

lelandfe

27 minutes 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

8 minutes ago

To be fair, implementing something like Spotify 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?

DavidPiper

2 hours ago

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

j16sdiz

4 minutes ago

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

oakinnagbe

an hour ago

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

jerf

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

notarobot123

an hour ago

Mass adoption trumps good design every time.

Surac

an hour 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

notesinthefield

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

comrade1234

an hour 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

41 minutes ago

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

RIshabh235

2 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

28 minutes 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

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

jerf

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

matt_kantor

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

varun_ch

an hour 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

an hour ago

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

inigyou

an hour ago

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

arkadiytehgraet

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

naveen99

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