Live data from Hacker News

The Birth and Death of JavaScript (2014)

destroyallsoftware.com

21–30 of 144 posts

Re: The Birth and Death of JavaScript (2014)

#21
post #11

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

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, beca…

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

Re: The Birth and Death of JavaScript (2014)

#22
post #5

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

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

Re: The Birth and Death of JavaScript (2014)

#23
post #11

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

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

Re: The Birth and Death of JavaScript (2014)

#24
post #11

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

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

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

Re: The Birth and Death of JavaScript (2014)

#25

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.

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.

Re: The Birth and Death of JavaScript (2014)

#26
post #11

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

> 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

Re: The Birth and Death of JavaScript (2014)

#28

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

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.

Re: The Birth and Death of JavaScript (2014)

#29
post #4

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.

I review many sites/month from different clients. They are all using some form of JavaScript. It's like PHP, it will never die.

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

Re: The Birth and Death of JavaScript (2014)

#30

Earlier quoted context omitted.

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

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

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