5 ms·

Despite the author's obvious enthusiasm: WASM has a long way to go before it is really useful. From my humble perspective there was not much progress since the

by Rochus 6y ago

Despite the author's obvious enthusiasm: WASM has a long way to go before it is really useful. From my humble perspective there was not much progress since the 1.0 release. As long as every access to the host (especially the GUI) is tunneled via JavaScript, one shouldn't be surprised about the low performance and the enormous memory consumption. See what happens behind the scenes when you set a pixel in the SDL API when running a WASM app in the browser. And there are plenty of good alternatives for the desktop already.

mgoetzke 6y ago
True, but we have a user-case where we have a library we could conceivably rewrite in e.g Rust and run multithreaded on the server or single-threaded inside a Webworker compiled as Wasm. This is for a pure logic component of course
- Rochus 6y ago
  Wasn't it the primary intention of WASM/Emscripten that you precisely don't have to rewrite existing libraries, but simply compile them for WASM and reuse them in the browser?
flohofwoe 6y ago
Calling from WASM to JS is "reasonably fast" now, of course it doesn't make any sense to make such a call for setting a single pixel, but this doesn't make sense anywhere else either. IMHO the current main problem of WASM running in browsers is not WASM, but that most "HTML5 APIs" are too high level, too specialized, and built under the assumption that Javascript is too slow to allow lower level, more general APIs (worst example of this outdated thinking is WebAudio). The next problem is: browser updates regularly break things, often unintended, but sometimes intended (like Chrome's splendid decision to start WebAudio contexts muted, which broke pretty much every WebAudio demo on the web). And finally: Features behind "security gates", some features just show a passive popup - but not that different browsers could ever agree on what the best UX is for this, each one behaves differently), other features show a popup that requires a user interaction. Other feature can only be used from within in a "short-lived input event handler". Yet other features only work over a HTTPS connection. And yet other features require specific response headers to be set by the web servers (like SharedArrayBuffer support in Firefox, and probably soon-ish Chrome). Please browser vendors I beg of you, make up your damn mind already about how to handle such security-sensitive features in a consistent way. Then there's the always lingering deprecation threat, like WebAudio's ScriptProcessorNode, despite it working perfectly fine for situations where audio samples must be generated on the browser thread and audio synthesis can't be moved into the audio thread) All of this combined makes the browser platform a quite frustrating platform to work on for anything that isn't very simple webpages. Not as bad as Android development (which is at the bottom of my list), but it's starting to get close. PS: Despite my ranting, I do actually like writing WASM stuff and putting it up on the web, at least this can be done without going through hoops like on closed platforms (e.g. Android or iOS). But it really could be better. Most of the actual problems are not something the people working on WASM can do anything about though.
- Rochus 6y ago
  > but this doesn't make sense anywhere else either But that's exactly what happens when you draw into an SDL raster window. Even when you have vector drawing operations on higher level, eventually pixels are modified; you can of course combine drawing operations and transport a patch of the screen to the host, but this still goes through an impressive machinery with a lot of copying. > All of this combined makes the browser platform a quite frustrating platform to work on for anything that isn't very simple webpages Well, eventually we're on the same page.
  - flohofwoe 6y ago
    SDL also does other weird things (or at least did), like rendering each 2D sprite in its own draw call. The way to handle something like setting unique pixels is to keep a pixel buffer in memory on the WASM side, set the pixels in there, and then once per frame copy this pixel buffer into a WebGL texture and render this through a single WebGL draw call, or blit the pixel buffer to a 2D canvas if WebGL is not an option (also once per frame).
    - Rochus 6y ago
      Unfortunately with WASM we don't have so many other ways to migrate a desktop GUI application at the moment. If I have to redesign the whole existing GUI application to run on WASM, the technology is not really attractive.
NationalPark 6y ago
I think you have the performance differences backwards, wasm is usually quite a bit faster than comparable javascript. While it's true that right now there are additional overhead costs for browser APIs, that's changing, but it's also misunderstanding the value proposition of wasm. You can write an entire front end web application if you want, but it really shines for library code and computationally expensive code. And of course, the distribution benefits mentioned in the article.
- Rochus 6y ago
  > wasm is usually quite a bit faster than comparable javascript Even if true, it doesn't help much if you have to marshall through JS for nearly every call. > You can write an entire front end web application if you want One of the core benefit propositions was the possibility to write browser applications in any language, not just JS.
  - NationalPark 6y ago
    I think you're just misunderstanding what wasm is. Writing browser applications in any language was never a "core benefit proposition", it was just something that you could do with the tooling. The value has always been in the library/platform layer. Objectively pure wasm is faster than pure javascript, subjectively the additional type safety from writing in Rust (which is practically speaking what most people shipping wasm write their source code in) makes people more confident that their complex code works. Outside of a few hobbyists, nobody is writing entire web applications in wasm. We already have great frameworks for dealing with UI/DOM stuff.
    - Rochus 6y ago
      To quote from https://webassembly.org/ https://webassembly.org/: "Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." So did they mean only GUI-less client applications? EDIT: also e.g. this source https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... makes it clear that porting e.g. C++ GUI applications is an intended feature, not just a silly idea of some hobbyists.
tester34 6y ago
>WASM has a long way to go before it is really useful. I disagree. I can already write decent C# applications that run in browser while using already existing C# libraries for e.g parsing text and it will run fine. So, WebAssembly allows me to use existing code C# and move it to the browser while developing in my fancy language instead of Javascript and I think it (dropping js) is very solid pros I just think tooling (visual studio, vs code, rider, etc...) around C#'s Blazor has to mature in order to make this kind of development worth considering, but I wouldnt call that "long way to go"
- Rochus 6y ago
  > I can already write decent C# applications that run in browser .. it will run fine. It is undoubtedly technically possible, but not really practicable, unless you accept an exorbitant speed-down and much higher memory consumption than e.g. when running in DotNet. Personally, I don't find that attractive in any way, nor do I find it particularly efficient.
  - tester34 6y ago
    I've been trying it on small CRUDs, so nothing impressive was happening on the front side, so I didn't really notice those problems. I think DLLs size and lack of DOM access was the biggest problem at the moment I've been testing it
    - Rochus 6y ago
      Try with a representative application where a whole JS based single page app is implemented in another language than JS (e.g. C++/Qt), which is one of the core benefit propositions made by WASM.
wffurr 6y ago
It does feel like WebAssembly development has stalled after the initial release. There are proposals for reference types, garbage collection, and host bindings that would greatly expand a WebAssembly binary's capabilities, but they haven't been implemented in any browser, much less standardized yet. WebAssembly proposals tracker: https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals WebAssembly reference types (https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p...) looks like the blocker for a lot of things, and it's in the final spec phase at least. In Chrome, it's behind a flag since 78, which went stable in Oct 22 2019: https://chromestatus.com/features/5166497248837632 https://chromestatus.com/features/5166497248837632 But also under active development? https://bugs.chromium.org/p/v8/issues/detail?id=7581 https://bugs.chromium.org/p/v8/issues/detail?id=7581 Supposedly implemented in Firefox two years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1444925 https://bugzilla.mozilla.org/show_bug.cgi?id=1444925 Nothing in Safari, of course. Where is it now though?
- Rochus 6y ago
  That is also my impression. And the fact that Mozilla has problems and has to realign is certainly not helping.
- maxgraey 6y ago
  > but they haven't been implemented in any browser, much less standardized yet. Reference types already implemented. GC is not really needed for non-managed languages like C++ or Rust. Interface types in progress. See this: https://webassembly.org/roadmap https://webassembly.org/roadmap
- wtetzner 6y ago
  I'm still waiting for tail call optimization. By not having support for it, a bunch of languages are either forced to not bother with WASM, or have to do something like trampolines and give up performance.
CyberDildonics 6y ago
> low performance and the enormous memory consumption That has not been what I've seen from it. People have made video editors and ported game into web pages. You make a lot of claims in this thread about speed and memory but don't back any of them up.
- Rochus 6y ago
  Here are some examples: https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly ; some of them don't even start on my 32 bit machine because more than 2GB RAM would need to be allocated. EDIT: I'm using Firefox 78.0.2 on Linux i386.
  - CyberDildonics 6y ago
    These load in about 1 second for me and everything is almost instant and fluid on firefox 80. The firefox process running them uses 284MB of memory.
    - Rochus 6y ago
      On which OS? Have you watched peak memory use, or is this steady state?
  - wenc 6y ago
    Just tried the pizza shop example on my desktop. Linux x86-64 (i7 quad core, 8GB RAM, Firefox 80.0.1) FF memory usage: blank page = 285MB, peak = 839MB, steady-state = 340MB. Load time: ~6s wall clock time. Tried it with my Windows 10 Desktop too (i7 quad core, 32GB RAM, Firefox 80.0.1). FF memory usage: blank page = 215MB, peak = 1015MB, steady-state = 658MB. Load time: ~3s wall clock time. Once loaded, the UI was very responsive.
    - Rochus 6y ago
      Thanks for the measurements. That's much faster indeed than on my laptop and even quite decent (besides the peak memory use). Compared to the C++ native version of similar apps on my Linux i386 and Windows x86 this is about factor 10/20 (Linux/Windows) more RAM in steady state and factor 25/30 (Linux/Windows) in peak. Start time of the C++ apps (not QML) is factor 6/3 (Linux/Windows) slower. Btw. I noticed that on my machine memory use is higher on Chromium and performance even worse than with Firefox. So it seems to depend on browser type/version, and someone in this thread said that there is no support for Safari.
ralphc 6y ago
Google seems to think it is currently useful. They have a WASM back end to tensorflow.js to use when WebGL isn’t available and you only have CPUs to run on https://blog.tensorflow.org/2020/03/introducing-webassembly-backend-for-tensorflow-js.html https://blog.tensorflow.org/2020/03/introducing-webassembly-...
wenc 6y ago
Microsoft is betting on (the not yet mature) Blazor [1,2] framework for porting .NET applications to WASM. Here's a CRUD app WASM example [3] -- there's an initial load time, but once loaded the app seems pretty responsive. There's a bunch more demos here [4] to get a sense of the performance. There's even a HN clone built on Blazor [5]. This very thread can be found there. [1] https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor [2] https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-now-available/ https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2... [3] https://becksblazor.azurewebsites.net https://becksblazor.azurewebsites.net [4] https://github.com/StevenTCramer/awesome-blazor#samples-and-tutorials https://github.com/StevenTCramer/awesome-blazor#samples-and-... [5] http://blazorhackernews.surge.sh http://blazorhackernews.surge.sh

by Rochus 6y ago

mgoetzke 6y ago

True, but we have a user-case where we have a library we could conceivably rewrite in e.g Rust and run multithreaded on the server or single-threaded inside a Webworker compiled as Wasm. This is for a pure logic component of course

Rochus 6y ago
Wasn't it the primary intention of WASM/Emscripten that you precisely don't have to rewrite existing libraries, but simply compile them for WASM and reuse them in the browser?

flohofwoe 6y ago

Calling from WASM to JS is "reasonably fast" now, of course it doesn't make any sense to make such a call for setting a single pixel, but this doesn't make sense anywhere else either. IMHO the current main problem of WASM running in browsers is not WASM, but that most "HTML5 APIs" are too high level, too specialized, and built under the assumption that Javascript is too slow to allow lower level, more general APIs (worst example of this outdated thinking is WebAudio). The next problem is: browser updates regularly break things, often unintended, but sometimes intended (like Chrome's splendid decision to start WebAudio contexts muted, which broke pretty much every WebAudio demo on the web). And finally: Features behind "security gates", some features just show a passive popup - but not that different browsers could ever agree on what the best UX is for this, each one behaves differently), other features show a popup that requires a user interaction. Other feature can only be used from within in a "short-lived input event handler". Yet other features only work over a HTTPS connection. And yet other features require specific response headers to be set by the web servers (like SharedArrayBuffer support in Firefox, and probably soon-ish Chrome). Please browser vendors I beg of you, make up your damn mind already about how to handle such security-sensitive features in a consistent way. Then there's the always lingering deprecation threat, like WebAudio's ScriptProcessorNode, despite it working perfectly fine for situations where audio samples must be generated on the browser thread and audio synthesis can't be moved into the audio thread) All of this combined makes the browser platform a quite frustrating platform to work on for anything that isn't very simple webpages. Not as bad as Android development (which is at the bottom of my list), but it's starting to get close. PS: Despite my ranting, I do actually like writing WASM stuff and putting it up on the web, at least this can be done without going through hoops like on closed platforms (e.g. Android or iOS). But it really could be better. Most of the actual problems are not something the people working on WASM can do anything about though.

Rochus 6y ago
> but this doesn't make sense anywhere else either But that's exactly what happens when you draw into an SDL raster window. Even when you have vector drawing operations on higher level, eventually pixels are modified; you can of course combine drawing operations and transport a patch of the screen to the host, but this still goes through an impressive machinery with a lot of copying. > All of this combined makes the browser platform a quite frustrating platform to work on for anything that isn't very simple webpages Well, eventually we're on the same page.
- flohofwoe 6y ago
  SDL also does other weird things (or at least did), like rendering each 2D sprite in its own draw call. The way to handle something like setting unique pixels is to keep a pixel buffer in memory on the WASM side, set the pixels in there, and then once per frame copy this pixel buffer into a WebGL texture and render this through a single WebGL draw call, or blit the pixel buffer to a 2D canvas if WebGL is not an option (also once per frame).
  - Rochus 6y ago
    Unfortunately with WASM we don't have so many other ways to migrate a desktop GUI application at the moment. If I have to redesign the whole existing GUI application to run on WASM, the technology is not really attractive.

NationalPark 6y ago

I think you have the performance differences backwards, wasm is usually quite a bit faster than comparable javascript. While it's true that right now there are additional overhead costs for browser APIs, that's changing, but it's also misunderstanding the value proposition of wasm. You can write an entire front end web application if you want, but it really shines for library code and computationally expensive code. And of course, the distribution benefits mentioned in the article.

Rochus 6y ago
> wasm is usually quite a bit faster than comparable javascript Even if true, it doesn't help much if you have to marshall through JS for nearly every call. > You can write an entire front end web application if you want One of the core benefit propositions was the possibility to write browser applications in any language, not just JS.
- NationalPark 6y ago
  I think you're just misunderstanding what wasm is. Writing browser applications in any language was never a "core benefit proposition", it was just something that you could do with the tooling. The value has always been in the library/platform layer. Objectively pure wasm is faster than pure javascript, subjectively the additional type safety from writing in Rust (which is practically speaking what most people shipping wasm write their source code in) makes people more confident that their complex code works. Outside of a few hobbyists, nobody is writing entire web applications in wasm. We already have great frameworks for dealing with UI/DOM stuff.
  - Rochus 6y ago
    To quote from https://webassembly.org/ https://webassembly.org/: "Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." So did they mean only GUI-less client applications? EDIT: also e.g. this source https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... makes it clear that porting e.g. C++ GUI applications is an intended feature, not just a silly idea of some hobbyists.

tester34 6y ago

>WASM has a long way to go before it is really useful. I disagree. I can already write decent C# applications that run in browser while using already existing C# libraries for e.g parsing text and it will run fine. So, WebAssembly allows me to use existing code C# and move it to the browser while developing in my fancy language instead of Javascript and I think it (dropping js) is very solid pros I just think tooling (visual studio, vs code, rider, etc...) around C#'s Blazor has to mature in order to make this kind of development worth considering, but I wouldnt call that "long way to go"

Rochus 6y ago
> I can already write decent C# applications that run in browser .. it will run fine. It is undoubtedly technically possible, but not really practicable, unless you accept an exorbitant speed-down and much higher memory consumption than e.g. when running in DotNet. Personally, I don't find that attractive in any way, nor do I find it particularly efficient.
- tester34 6y ago
  I've been trying it on small CRUDs, so nothing impressive was happening on the front side, so I didn't really notice those problems. I think DLLs size and lack of DOM access was the biggest problem at the moment I've been testing it
  - Rochus 6y ago
    Try with a representative application where a whole JS based single page app is implemented in another language than JS (e.g. C++/Qt), which is one of the core benefit propositions made by WASM.

wffurr 6y ago

It does feel like WebAssembly development has stalled after the initial release. There are proposals for reference types, garbage collection, and host bindings that would greatly expand a WebAssembly binary's capabilities, but they haven't been implemented in any browser, much less standardized yet. WebAssembly proposals tracker: https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals WebAssembly reference types (https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p...) looks like the blocker for a lot of things, and it's in the final spec phase at least. In Chrome, it's behind a flag since 78, which went stable in Oct 22 2019: https://chromestatus.com/features/5166497248837632 https://chromestatus.com/features/5166497248837632 But also under active development? https://bugs.chromium.org/p/v8/issues/detail?id=7581 https://bugs.chromium.org/p/v8/issues/detail?id=7581 Supposedly implemented in Firefox two years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1444925 https://bugzilla.mozilla.org/show_bug.cgi?id=1444925 Nothing in Safari, of course. Where is it now though?

Rochus 6y ago
That is also my impression. And the fact that Mozilla has problems and has to realign is certainly not helping.
maxgraey 6y ago
> but they haven't been implemented in any browser, much less standardized yet. Reference types already implemented. GC is not really needed for non-managed languages like C++ or Rust. Interface types in progress. See this: https://webassembly.org/roadmap https://webassembly.org/roadmap
wtetzner 6y ago
I'm still waiting for tail call optimization. By not having support for it, a bunch of languages are either forced to not bother with WASM, or have to do something like trampolines and give up performance.

CyberDildonics 6y ago

> low performance and the enormous memory consumption That has not been what I've seen from it. People have made video editors and ported game into web pages. You make a lot of claims in this thread about speed and memory but don't back any of them up.

Rochus 6y ago
Here are some examples: https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly ; some of them don't even start on my 32 bit machine because more than 2GB RAM would need to be allocated. EDIT: I'm using Firefox 78.0.2 on Linux i386.
- CyberDildonics 6y ago
  These load in about 1 second for me and everything is almost instant and fluid on firefox 80. The firefox process running them uses 284MB of memory.
  - Rochus 6y ago
    On which OS? Have you watched peak memory use, or is this steady state?
- wenc 6y ago
  Just tried the pizza shop example on my desktop. Linux x86-64 (i7 quad core, 8GB RAM, Firefox 80.0.1) FF memory usage: blank page = 285MB, peak = 839MB, steady-state = 340MB. Load time: ~6s wall clock time. Tried it with my Windows 10 Desktop too (i7 quad core, 32GB RAM, Firefox 80.0.1). FF memory usage: blank page = 215MB, peak = 1015MB, steady-state = 658MB. Load time: ~3s wall clock time. Once loaded, the UI was very responsive.
  - Rochus 6y ago
    Thanks for the measurements. That's much faster indeed than on my laptop and even quite decent (besides the peak memory use). Compared to the C++ native version of similar apps on my Linux i386 and Windows x86 this is about factor 10/20 (Linux/Windows) more RAM in steady state and factor 25/30 (Linux/Windows) in peak. Start time of the C++ apps (not QML) is factor 6/3 (Linux/Windows) slower. Btw. I noticed that on my machine memory use is higher on Chromium and performance even worse than with Firefox. So it seems to depend on browser type/version, and someone in this thread said that there is no support for Safari.

ralphc 6y ago

Google seems to think it is currently useful. They have a WASM back end to tensorflow.js to use when WebGL isn’t available and you only have CPUs to run on https://blog.tensorflow.org/2020/03/introducing-webassembly-backend-for-tensorflow-js.html https://blog.tensorflow.org/2020/03/introducing-webassembly-...

wenc 6y ago

Microsoft is betting on (the not yet mature) Blazor [1,2] framework for porting .NET applications to WASM. Here's a CRUD app WASM example [3] -- there's an initial load time, but once loaded the app seems pretty responsive. There's a bunch more demos here [4] to get a sense of the performance. There's even a HN clone built on Blazor [5]. This very thread can be found there. [1] https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor [2] https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-now-available/ https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2... [3] https://becksblazor.azurewebsites.net https://becksblazor.azurewebsites.net [4] https://github.com/StevenTCramer/awesome-blazor#samples-and-tutorials https://github.com/StevenTCramer/awesome-blazor#samples-and-... [5] http://blazorhackernews.surge.sh http://blazorhackernews.surge.sh