3 ms·

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 al

by Rochus 5y ago

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/ 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 ago
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.
- 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 ago
    I think they meant embedded as in "Windows Embedded Edition".
  - cygx 5y ago
    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_Configuration#Typical_requirements https://en.wikipedia.org/wiki/Connected_Limited_Device_Confi...
  - pjmlp 5y ago
    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).
    - Rochus 5y ago
      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?
      - pjmlp 5y ago
        It is fast enough for bringing back Flash like experience. https://platform.uno/uno-platform-for-web-webassemby https://platform.uno/uno-platform-for-web-webassemby https://leaningtech.com/cheerpx-for-flash/ https://leaningtech.com/cheerpx-for-flash/ Or Java applets https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ Or Silverlight https://opensilver.net/ https://opensilver.net/
badsectoracula 5y ago
> 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.
- sirwhinesalot 5y ago
  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.
- Rochus 5y ago
  > 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.

by Rochus 5y ago

cygx 5y ago

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.

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 ago
  I think they meant embedded as in "Windows Embedded Edition".
- cygx 5y ago
  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_Configuration#Typical_requirements https://en.wikipedia.org/wiki/Connected_Limited_Device_Confi...
- pjmlp 5y ago
  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).
  - Rochus 5y ago
    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?
    - pjmlp 5y ago
      It is fast enough for bringing back Flash like experience. https://platform.uno/uno-platform-for-web-webassemby https://platform.uno/uno-platform-for-web-webassemby https://leaningtech.com/cheerpx-for-flash/ https://leaningtech.com/cheerpx-for-flash/ Or Java applets https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ Or Silverlight https://opensilver.net/ https://opensilver.net/

badsectoracula 5y ago

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

sirwhinesalot 5y ago
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.
Rochus 5y ago
> 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.