Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Birth and Death of JavaScript (2014)

destroyallsoftware.com

Post reply on HN
Print view View original

81–90 of 144 posts

Re: The Birth and Death of JavaScript (2014)

#81

Post by pjmlp »

_the_inflator wrote: post #18
jdw64 wrote: 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 rarely can go wrong with JavaScript and Python, I would say.

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

Re: The Birth and Death of JavaScript (2014)

#82

Post by Veserv »

ksec wrote: post #68

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.

Re: The Birth and Death of JavaScript (2014)

#83

Post by Macha »

wiseowise wrote: post #25
RIshabh235 wrote: post #2

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.

The same is true of COBOL and Fortran. But also for most purposes, they are practically* dead.

* With the one exception of BLAS which is widely used via NumPy

Re: The Birth and Death of JavaScript (2014)

#84

Post by veqq »

jdw64 wrote: 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…

> the fastest way to support Mac, Windows, and Linux all at once

Tcl with TK or Free Pascal on Lazarus

Re: The Birth and Death of JavaScript (2014)

#85

Post by winrid »

veqq wrote: post #84
jdw64 wrote: 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…

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

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

Re: The Birth and Death of JavaScript (2014)

#86

Post by dnautics »

jdw64 wrote: 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…

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

Re: The Birth and Death of JavaScript (2014)

#87

Post by jschrf »

moritzwarhier wrote: post #65
noman-land wrote: post #40

Earlier quoted context omitted.

He was pretty close to being NaN% correct.

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.

Protip: never even mention undefined in your codebase. Erase it from your vernacular. If you ever need to pass or return nothing, you use null.

Re: The Birth and Death of JavaScript (2014)

#88

Post by moritzwarhier »

jschrf wrote: post #87
moritzwarhier wrote: post #65

Earlier quoted context omitted.

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.

Protip: never even mention undefined in your codebase. Erase it from your vernacular. If you ever need to pass or return nothing, you use null.

I do it this way, but this led to people asking me in reviews why I use NULL^^

My explanation was that it signals intent to me, and is different from some property not being part of the expected object shape or not having been initialized because of some accident or logic failure.

Since then, I've sticked to it, and am "allowed" to use NULL ^^

It can lead to some annoying checks in TS for primitively-typed properties, so for these, I still allow explicit usage of undefined when it's simpler given the surrounding code.

But I agree with you in principle. Using "undefined" as a "second nullish value" and explicitly checking for it is a programming error.

When there's object/areay vs null/undefined, thankfully, the truthiness narrowing often allows me to interface with code relying on "undefined" without explicitly handling this "value" in my own parts of the code base :)

Re: The Birth and Death of JavaScript (2014)

#89

Post by crdrost »

jschrf wrote: post #87
moritzwarhier wrote: post #65

Earlier quoted context omitted.

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.

Protip: never even mention undefined in your codebase. Erase it from your vernacular. If you ever need to pass or return nothing, you use null.

If you're a type purist then undefined looks nicer... It'd be like being upset at booleans because things get coerced to them or some 'ish.

No: it's the type that has one inhabitant—it's not that type's fault that it appears as a default argument or var or was left out of JSON... So long as typeof null === "object", null is the absurd one

Post reply on HN