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

51–60 of 144 posts

Re: The Birth and Death of JavaScript (2014)

#51

Post by satvikpendem »

moritzwarhier wrote: post #35
ifh-hn wrote: post #30

Earlier quoted context omitted.

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

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

Dioxus Native supports both web and native platforms because they serve HTML and CSS for the web and then on native they turn that into canvas rendered code just like Flutter, not a webview, because they built their own HTML and CSS renderer.

For Flutter web, yes as it's canvas based it doesn't have all the same web features but generally for crud apps it doesn't much matter, especially if it's near zero effort taking your Flutter mobile and desktop app and putting it on the web. With the new impeller renderer and Wasm improvements it has gotten quite faster too.

Re: The Birth and Death of JavaScript (2014)

#52

Post by satvikpendem »

wiseowise wrote: post #24
frail_figure wrote: post #20

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.

Where does it consume more than Electron?

Re: The Birth and Death of JavaScript (2014)

#53

Post by satvikpendem »

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.

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.

Re: The Birth and Death of JavaScript (2014)

#54

Post by satvikpendem »

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…

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.

Re: The Birth and Death of JavaScript (2014)

#55

Post by satvikpendem »

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

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.

Re: The Birth and Death of JavaScript (2014)

#56

Post by satvikpendem »

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.

Re: The Birth and Death of JavaScript (2014)

#57

Post by wffurr »

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.

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

Re: The Birth and Death of JavaScript (2014)

#58

Post by wffurr »

krautsauer wrote: post #23
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…

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

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

Re: The Birth and Death of JavaScript (2014)

#59

Post by Zigurd »

satvikpendem wrote: post #56

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.

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

Re: The Birth and Death of JavaScript (2014)

#60

Post by DonHopkins »

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

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

Post reply on HN