31 ms·
Why WebAssembly? Is this technology really still alive? Having a look at https://webassembly.org https://webassembly.org version 1.0 from 2017 is still advertis
by Rochus 5y ago
Why WebAssembly? Is this technology really still alive? Having a look at https://webassembly.org https://webassembly.org version 1.0 from 2017 is still advertised.
- samwillis 5y agoWhile 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/ 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.
- Rochus 5y agoThank 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/ 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.
- cygx 5y agoSo 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.
- Rochus 5y ago> 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.
- tormeh 5y agoI think they meant embedded as in "Windows Embedded Edition".
- cygx 5y agothe 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_Configuration#Typical_requirements https://en.wikipedia.org/wiki/Connected_Limited_Device_Confi...
- badsectoracula 5y agoThe site mentions that 1.0 is implemented by four major browser engines but the spec that it provides is 1.1 which is still being developed (last update was just a couple of weeks ago). Though it is annoying that you can't find the 1.0 spec - you know, the one that actually works - in the site. You can find it[0] at W3C by clicking around the W3C links in the site, but there isn't a direct link. Also annoying that there isn't any downloadable form (the SingleFile extension on Firefox seems to work though). [0] https://www.w3.org/TR/wasm-core-1/ https://www.w3.org/TR/wasm-core-1/
- phendrenad2 5y agoThe wasm dream died when in 2017 you couldn't modify the DOM. It was "coming soon". And then in 2018, 2019, 2020, 2021, 2022, and presumably for it's entire future, it's still "coming soon" (actually, most people have given up on it ever happening at this point, so no one says "coming soon" except the grossly uninitiated).
- mikewarot 5y agoThe only selling point of WebAssembly for me is the sandbox. P-code, Java, and .NET all allow applications to directly access files in the host system, which leads to a wide range of security problems. WebAssembly defaults to having NO access to the hosts file system. This makes it safe to run ANYTHING inside a WebAssembly interpreter without risk of having it escape and ruin the host system. As long as they don't get stupid and provide host file system access, I'll keep putting time into learning about it.