[torginus]

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.

[ttd]

There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).

[torginus]

NaCL was further along in every meaningful dimension (the ability to run native software at native speeds) after a year or two of development, than WASM is today after a decade (and I think this will be true a decade from now).

So the upside of WASM according to you, is that it got greenlit by the standards committee chaired by companies whose business model would've been hurt the most by a competent in-browser sandbox.

For example, the Epic-Apple Fortnite battle couldn't even have happened. Epic would've shipped it on NaCL and users would've been just as happy, and Apple (or Google) would've had no way of enforcing their sandox.

Whew, thankfully we've been saved from that terrible fate of getting to publish and enjoy software without gatekeepers and appstores.

At least I hope you have something to gain from your opinion, as the rest of us certainly lost out.

[ttd]

It seems like you know quite a bit of the history here. Were you involved in some way? If so, I'm curious to know why you think NaCL did not achieve broad adoption? And what's stopping the world from catching up to your line of thinking and adopting a NaCL successor?

[torginus]

> Were you involved in some way?

Only as a developer using the technology, as part of a failed commercial venture.

> If so, I'm curious to know why you think NaCL did not achieve broad adoption?

NaCl had 2 limitations compared to WASM, the first one was a design philosophy difference:

Unlike WASM, it was designed to maximize compatibility with native code, so it had no ability to coexist in the same process with JS/DOM like WASM does. You had to put the code in an iframe, and talk to it via postMessage. WASM promised to be a better design, but a decade on, we can see it's missing most of those promised features, or said features are half-baked, and it has turned into one of the biggest NIH quests in modern computer science.

The second issue was that it worked through Chrome's plugin API, which has since been deprecated. You could sit down and standardize an API that's not chrome specific. The biggest piece of API surface the browser has is WebGL, and they essentially exposed OpenGL ES to the browser, which is identical to what PPAPI did.

Some APIs were much better, like audio just gave you a buffer to write into, compared to WebAudio, which aims to implement the whole processing pipeline via stringing together JS objects, and everybody seems to hate it.

> And what's stopping the world from catching up to your line of thinking and adopting a NaCL successor?

Theoretically nothing, but you'd have to fork Chrome, do the changes yourself, develop a spec and tooling and THEN ask browser vendors to standardize on your changes. If there was some soul who would undertake this task (maybe feasible with AI for a non-huge team?), combined with a strong awareness campaign to get committees to consider adoption. So it's a tall order in reality.

[torginus]

I also have to add, that I think that WASM is the wrong approach - basically I get what they were going for but they should've either merged the JS and WASM 'worlds' so that these 2 pieces of code can interact without any friction, and are handled by the same VM. This would've allowed things like gradually compiling a JS codebase to WASM.

Alternatively, the should've stuck with the NaCL approach of two separate, isolated worlds, with maximum compatibility and peformance for native code.

[inigyou]

Surely PNaCl is the one you need, because portability.

[torginus]

Portability isn't worth as much as it was advertised. There are a grand total of 2 relevant CPU architectures for consumers, ARM64 and x86_64. Shipping 2 binaries is just running the compiler twice.

On the client side, there's just a verifier, and then the runtime basically consists of branching to the first instruction and having at it. Near-native performance and instant startup, you can't do better than that.

PNaCL was proto-WebAssembly and suffering from the same issues. They actually shipped LLVM bytecode, and you had to compile the executable locally with the whole toolchain, leading to quite bad startup performance and a lot of baggage.

Turns out there's no such thing as portable VM assembly. You still have to ship a full compiler (well, JIT) and compile the WASM IR.

Browser vendors have spent uncountable amount of engineering resources on making yet another compiler (actually multiple, since afaik Chrome uses a tiered JIT for WASM), that's neither as good as the big boys, and neither as fast as just running the dang binary.

[inigyou]

If you make the web dependent on a CPU architecture, you're giving up on a fundamental design principle and also letting one company control it.

[torginus]

Linux distros are shipped as binaries yet you can still build them from source, and are certainly not controlled by one company, I don't see why that would be the case here.

[pjmlp]

PNaCL was published with a standard and tooling, it was Mozzilla that refused to adopt it, and push asm.js instead.

Ironically, if it was today, Google could have pushed PNaCL without any problem.

[hypendev]

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

Working on that! I'm building hypen.space which is platform agnostic language & SDK for building native crossplatform apps.

It's a WASM engine at it's core, and while currently it doesn't have "package this app as wasm" capability but supports streaming/local apps only, that capability is currently being developed - together with WASI layers for all of the platforms.

That way your app can run either as a browser (DOM) app, browser canvas app, native desktop or native mobile app.

It's still early, but moving fast - I just added accessibility support, and the animation framework will be out this week.

Regarding the WASM disappointed, when I started building this about 6 years ago, WASM was in a terrible (barely usable without wasting a ton of time) state. Now that WASI 0.3 is out and LLMs have sped up development by a large margin, it's in a quite usable state to ship things to production without fear.

[mckee_plus_plus]

Crediting LLMs with advancing wasm is a disservice to the best-in-industry bytecodealliance community & org.

[hypendev]

You might have misread me - I meant in a time when LLM's are speeding up development in general, as now you can write giant interfaces and implementations without having to manually deal with glue code.