logoalt Hacker News

shevy-javatoday at 10:25 AM3 repliesview on HN

WASM will be ready when GNU Hurd succeeds in running the desktop linux of the year. Already 10 years since WASM ... HTML, CSS and JavaScript all had a huge influence. WAS simply has not done so yet.


Replies

boomskatstoday at 10:42 AM

Ready for what?

WASM is already running in production at a whole bunch of financial services orgs and government infra.

The thing is, it's not running anywhere near HTML, CSS or JavaScript. It's running serverside, mostly on Wasmtime - which, as it happens, is what this post is all about.

show 2 replies
bobajefftoday at 12:48 PM

I'm not sure why people are claiming wasm isn't ready. It's just a compiler target like asm.js was. And that's been in use pretty much from the start when they got Unreal Engine, Unity, ffmpeg ported to it. Personally I've run Python + Sympy, Xcas/Giac and Maxima in the browser through this amazing tech.

torginustoday at 11:27 AM

Yeah, WASM has been a disappointment, and I guess there's a good reason for that. If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead.

Native Client, which ran native x86 (but statically verified) code in the browser, basically fit all the criteria, except it wasn't platform agnostic. I'm not married to their approach, but I refuse to believe that this can't be done in a safe and peformant manner.

I guess WASM turned out to be a sandbagging rather than sandboxing technology.

But I eagearly await the arrival of concern trolls who can explain why WASM is slower than JS, and why native threading support is impossible to do securely without imposing limitations, that made sites like itch turn it off, so it might as well not exist.

show 2 replies