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

41–50 of 144 posts

Re: The Birth and Death of JavaScript (2014)

#41

Post by ymolodtsov »

moritzwarhier wrote: post #36
lelandfe wrote: post #26

Earlier quoted context omitted.

> 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

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…

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.

Re: The Birth and Death of JavaScript (2014)

#42

Post by afavour »

Surac wrote: 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

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

Re: The Birth and Death of JavaScript (2014)

#43

Post by neonstatic »

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…

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

Re: The Birth and Death of JavaScript (2014)

#44

Post by jdw64 »

Dwedit wrote: post #38
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…

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.

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

Re: The Birth and Death of JavaScript (2014)

#45

Post by Uehreka »

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

Re: The Birth and Death of JavaScript (2014)

#46

Post by cxr »

saghm wrote: post #33
_the_inflator wrote: post #18

Earlier quoted context omitted.

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…

> 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 jus…

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

Re: The Birth and Death of JavaScript (2014)

#47

Post by vips7L »

frail_figure wrote: post #20
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…

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

Darts an amazing language too.

Re: The Birth and Death of JavaScript (2014)

#48

Post by TheOtherHobbes »

falcor84 wrote: post #22
Surac wrote: 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?

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

Re: The Birth and Death of JavaScript (2014)

#50

Post by bee_rider »

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…

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.”
Post reply on HN