Hacker News Reader

Comment by vbezhenar | Hacker News Reader

You can use javascript as a single cross platform compile target. What's the difference?

Javascript comes with mandatory garbage collection. I suppose you could compile any language to an allocation-free semantic subset of Javascript, but it's probably going to be even less pretty than transpiling to Javascript already is.

> it's probably going to be even less pretty than transpiling to Javascript already is.

I don't see how it'd be much different to compiling to JavaScript otherwise. Isn't it usually pretty clear where allocations are happening and how to avoid them?

“Pretty clear” is good, “guaranteed by language specifications” is better.

Why reverse-engineer each JS implementation if you can just target a non-GC runtime instead?

WASM allows you to run some parts of the application a bit faster. ;)

WASM, and asm.js before it, roughly exist because Javascript is such a bad compile target.

WASM works with any language and can be much faster than javascript

You can compile any language to JavaScript. jslinux compiled x86 machine code to JavaScript.

So basically wasm is some optimisation. That's fine but it's not something groundbreaking.

And if we remove web from the platform list, there were many portables bytecodes. P-code from Pascal era, JVM bytecode from modern era and plenty of others.

> some optimisation

That's underselling it a bit IMO. There's a reason asm.js was abandoned.

Wikipedia mentions that Wasm is faster to parse than asm.js, and I'm guessing Wasm might be smaller, but is there any other reason? I don't think there's any reason for asm.js to have resulted in slower execution than Wasm.

> I don't think there's any reason for asm.js to have resulted in slower execution than Wasm

The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...

Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then.

Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.

After reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years.

I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser.

The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark.

Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.

Whatever it would have ended up like it would have been a big hack so I'm glad everyone agreed to go with a proper solution for once!

Both undersell and oversell. There are still cases where vanilla JS will be faster.

And AFAIK asm.js is the precursor to WASM, like the early implementations just built on top of asm.js's primitives.

Reply on news.ycombinator.com