Comment by samwillis | Hacker News Reader

Comment by samwillis | Hacker News Reader

Parent Full thread

While the WASM spec is developing slowly some people (myself included) believe it’s going to become not just a standard for computation and a compiler target in the browser but elsewhere too.

First for an example of what is possible with WASM take a look at Figma, they have a custom vector graphics rendering engine built in C++ compiled to WASM and using WebGL. The performance is incredible for a web app.

WASM is going to take over much of the cloud server market as well. Initially at the “edge” and cloud functions (see CloudFlare workers). But it’s increasingly going to be the standard deployment target. Rust and C++ have first class support for it, over dynamic language such as Python will so be able to run under WASM very soon (Python is just about there).

It’s basically perfect for app plugins as it’s naturally sandboxed. More software will provide a WASM plugin architecture.

Take a look at WASI (https://wasi.dev/), they are working to standardise a system interface for outside the browser.

Finally I also think the embedded market is a possible target for it. Many of the places that currently run an embedded Java VM will potentially use a WASM system in the future.

Thank you for your explanations.

> but elsewhere too

I noticed that there seem to be more "elsewhere" than "browser" applications of the technology. But we already have e.g. the Mono engine with a proven, standardized IL which already offers most of the WASM features planned for the "elsewhere" use case. The engine can be run with just an executable and a core library with less than 10MB on a myriad of architectures (see e.g. https://github.com/rochus-keller/Oberon/ for a lean application of it). So what is WASM expected to bring to the table for this use case we don't already have today?

> a custom vector graphics rendering engine built in C++ compiled to WASM

Might be a nice idea, but there are already vector graphics libraries with included JIT and GPU backends. So what's the core benefit of using WASM here as an intermediate layer?

> But it’s increasingly going to be the standard deployment target

Do you have evidence for this? It has a lot of powerful competition, e.g. Go or native Java.

> I also think the embedded market is a possible target for it

"Embedded" is a very broad term. The vast majority of true embedded systems will not be able to afford running a VM, or even using dynamic memory - I e.g. do all my STM32 projects still in a subset of plain C. All embedded systems suited for Linux have a broad choice of proven viable technologies, from C to Python; even Mono is a viable solution on such systems.

So what is WASM expected to bring to the table for this use case we don't already have today?

It's the latest iteration of Java Applets, Flash, Silverlight, PNaCL, ...

If something gets re-invented over and over again, there clearly is a niche to fill.

"Embedded" is a very broad term. The vast majority of true embedded systems will not be able to afford running a VM, or even using dynamic memory.

Note that since 2007, Blue Ray players are required to run a JVM to support the 'bonus view' feature. The number of devices beefy enough to run VMs has only grown since.

> It's the latest iteration of Java Applets, Flash, Silverlight, PNaCL,

My question was about the "elsewhere" use case; I'm familiar with the original intention of WASM, and the technologies you mention are well covered by HTML5 and JS today.

> "The number of devices beefy enough to run VMs"

That's not the point. The point is that industry will rather use a cheep microcontroller still today if there is no justification for something more powerful, and these controllers cannot afford VMs or dynamic memory management. Of course there are always people running MicroPython or friends on MCUs, but this is a niche.

I think they meant embedded as in "Windows Embedded Edition".

the technologies you mention are well covered by HTML5 and JS today

Browser vendors could have decided to choose the pure Javascript route (eg asm.js, SIMD.js), but for now have decided to throw their weight behind WASM instead: SIMD.js got canned in 2017, whereas SIMD support for WASM shipped in browsers last year.

Regarding your second point about embedded devices, I can easily imagine WASM being used in the class of devices targeted by Java ME[1]. I'll of course happily defer to people who actually know something about the topic: If you think there's no legitimate use case for WASM in that space, so be it.

[1] https://en.wikipedia.org/wiki/Connected_Limited_Device_Confi...

They aren't so well covered, given how lacking the whole tooling is.

Thankfully WebAssembly + WebGL have brought them back, that is the only reason I appreciate WebAssembly (on the browser).

Interesting. But WebGL is a JS API, so you cannot directly access it with current WASM browser implementations, isn't it? I had a look at the Qt WASM implementation some time ago and found it extremely inefficient, not only because apparently everything has to be marshalled via JS. Has this improved in v1.1?

It is fast enough for bringing back Flash like experience.

https://platform.uno/uno-platform-for-web-webassemby

https://leaningtech.com/cheerpx-for-flash/

Or Java applets

https://leaningtech.com/cheerpj/

Or Silverlight

https://opensilver.net/

> I noticed that there seem to be more "elsewhere" than "browser" applications of the technology. But we already have e.g. the Mono engine with a proven, standardized IL which already offers most of the WASM features planned for the "elsewhere" use case.

Well, yeah, that is the thing. The idea and similar tech existed ever since P-Code for Pascal (and perhaps earlier) and of course the very popular - at the time at least - Java and its JVM, all of which predate Mono and IL and already had several open source implementations.

However just the tech isn't enough - in fact, if anything, the computing history shows that tech is rarely the winning factor in what gets accepted and becomes popular, it is largely social and political factors. In this case the "social" factor seems to be that this isn't just "more 'elsewhere' than 'browser' applications" but actually "'elsewhere' and 'browser' applications". The fact that browsers support WebAssembly natively (as opposed through some plugin like it was done for JVM/IL/Flash/etc - ie. similar tech) is a big social and political boost that it has. This is where the hype currently comes from.

Pretty much agreed, it comes down to a discussion I had why before C was the only real standard for language interoperability, and nothing else could ever be since there's no pressure for the language implementers to adopt anything else, because everyone else is using plain C as the only officially supported glue as well.

(OS vendors can have their own little things but it doesn't matter because it will never be adopted outside the OS and will only ever be used to talk to the OS).

This changes with WASM because if languages want to run in the browser, they need to target WASM, and suddenly there's a new standard that can put as much pressure in the language implementations as the C standard. This is the second time this has happened in history and I'm quite hopeful WASM and WASI catch on since C is complete jank as a glue language (even if it's used by everyone).

It all comes down to popularity and politics.

> Java and its JVM

WASM shares more ideas with CIL than the JVM, especially when we have a look at the WASM proposals in progress. CIL and Pascal P-Code in contrast to JVM support e.g. value objects which supports applications with less dynamic memory management; JVM requires a dynamic allocation for each fly speck and thus powerful compacting collectors to cope with it. In WASM the memory management strategy is up to the application.

> The fact that browsers support WebAssembly natively

I was referring to the "elsewhere" case, where WASM seems to flourish, not the browser. And the social factor is definitely important, but I'm more interested what WASM is supposed to deliver we don't already have on a technical level.

> WASM shares more ideas with CIL than the JVM [..] In WASM the memory management strategy is up to the application.

That level of difference doesn't matter. The point is that WASM is a portable and sandboxed target (like JVM) which is (or will be) faster, more secure (e.g. capability based security in WASI) and with more language support (strictly more when optional GC becomes a thing) and other differences are implementation details.

"Everything Old is New Again: Binary Security of WebAssembly"

https://www.usenix.org/conference/usenixsecurity20/presentat...

"WebAssembly Troubles"

http://troubles.md/wasm-is-not-a-stack-machine/

Reply on news.ycombinator.com