5 ms·

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

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.
    - jkelleyrtp 6y ago
      Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when providing computationally expensive features. My favorite example is Rapier http://rapier.rs/ http://rapier.rs/, check out the 3D demos. It blows every JS physics engine out of the water, and it’s using Conrod, a native gui library which has a webgl backend.
      - Rochus 6y ago
        Thanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.
        CyberDildonics 6y ago
        I tried the same thing and it took 4 seconds on my 8 year old computer.
        Rochus 6y ago
        Thanks for the info. My laptop has about the same age. Maybe you have the much faster graphics chip than my HP EliteBook.
        CyberDildonics 6y ago
        Drawing a few boxes with webgl has nothing to do with a graphics card. This is about webasm which is single core performance.
        Rochus 6y ago
- gameswithgo 6y ago
  >Even if true, it doesn't help much if you have to marshall through JS for nearly every call. If your particular front end code is dominated by many calls to the DOM, then WASM may be a net performance loss currently, yes. In cases where you are doing something computationally heavy then periodically updating the dom with results, then WASM can be a huge win. In cases where the performance is fine either way, being able to use one language server and client is a huge win. I am already doing useful things with WASM and Rust. It is a very very nice workflow.
- jdhbbbhb 6y ago
  Webassembly is not designed to replace javascript. It works along side it.
- Jasper_ 6y ago
  I've rewritten hot loops (decompression & texture detiling) from JavaScript into specialized AssemblyScript and seen a decent (2-3x) perf boost? I'm not sure how much of that is "running hot" in JS, since in the examples back then I was probably only doing it for ~100 textures. I can't imagine beating JS with a giant STL-using app with a clang-based toolchain, but the AOT nature helps a lot for hot loops; the kind of stuff you'd write custom asm for in a game engine. Of course I was making sure to do as minimal memory transfer as possible, and I already use a lot of weird patterns to try to minimize GC in JS. https://github.com/magcius/noclip.website/blob/master/src/gx/gx_texture.ts#L130-L156 https://github.com/magcius/noclip.website/blob/master/src/gx... https://github.com/magcius/noclip.website/blob/master/src/assembly/gx_texture_as.ts https://github.com/magcius/noclip.website/blob/master/src/as...
- swalsh 6y ago
  > Even if true, it doesn't help much if you have to marshall through JS for nearly every call. If you're doing a lot of cheap calls, it's probably not the optimal way to get a performance boost. I think Web Assembly shines at taking an expensive function, and doing it faster. For example, let's say I wanted to multiple a few large matricies of values. In Javascript this would be VERY slow. In Web Assembly it would be a bit faster, but then Web Assembly plus Web GPU allows me to do it REALLY fast. Yes, I'd then have to marshal the end result back to javascript but that's still cheaper then trying to do all that math natively in Javascript.

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.
  - jkelleyrtp 6y ago
    Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when providing computationally expensive features. My favorite example is Rapier http://rapier.rs/ http://rapier.rs/, check out the 3D demos. It blows every JS physics engine out of the water, and it’s using Conrod, a native gui library which has a webgl backend.
    - Rochus 6y ago
      Thanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.
      - CyberDildonics 6y ago
        I tried the same thing and it took 4 seconds on my 8 year old computer.
        Rochus 6y ago
        Thanks for the info. My laptop has about the same age. Maybe you have the much faster graphics chip than my HP EliteBook.
        CyberDildonics 6y ago
        Drawing a few boxes with webgl has nothing to do with a graphics card. This is about webasm which is single core performance.
        Rochus 6y ago
gameswithgo 6y ago
>Even if true, it doesn't help much if you have to marshall through JS for nearly every call. If your particular front end code is dominated by many calls to the DOM, then WASM may be a net performance loss currently, yes. In cases where you are doing something computationally heavy then periodically updating the dom with results, then WASM can be a huge win. In cases where the performance is fine either way, being able to use one language server and client is a huge win. I am already doing useful things with WASM and Rust. It is a very very nice workflow.
jdhbbbhb 6y ago
Webassembly is not designed to replace javascript. It works along side it.
Jasper_ 6y ago
I've rewritten hot loops (decompression & texture detiling) from JavaScript into specialized AssemblyScript and seen a decent (2-3x) perf boost? I'm not sure how much of that is "running hot" in JS, since in the examples back then I was probably only doing it for ~100 textures. I can't imagine beating JS with a giant STL-using app with a clang-based toolchain, but the AOT nature helps a lot for hot loops; the kind of stuff you'd write custom asm for in a game engine. Of course I was making sure to do as minimal memory transfer as possible, and I already use a lot of weird patterns to try to minimize GC in JS. https://github.com/magcius/noclip.website/blob/master/src/gx/gx_texture.ts#L130-L156 https://github.com/magcius/noclip.website/blob/master/src/gx... https://github.com/magcius/noclip.website/blob/master/src/assembly/gx_texture_as.ts https://github.com/magcius/noclip.website/blob/master/src/as...
swalsh 6y ago
> Even if true, it doesn't help much if you have to marshall through JS for nearly every call. If you're doing a lot of cheap calls, it's probably not the optimal way to get a performance boost. I think Web Assembly shines at taking an expensive function, and doing it faster. For example, let's say I wanted to multiple a few large matricies of values. In Javascript this would be VERY slow. In Web Assembly it would be a bit faster, but then Web Assembly plus Web GPU allows me to do it REALLY fast. Yes, I'd then have to marshal the end result back to javascript but that's still cheaper then trying to do all that math natively in Javascript.