7 ms·

Is WebAssembly magic performance pixie dust? (2021)

127 points by simonebrunozzi 4y ago

dvh 4y ago
How does it compare with canvas' blur filter, or boxblur canvas library?
RobbieGM 4y ago
He makes a point of showing how hard it is to achieve the same performance as JS with wasm, but the majority of the problems he runs into are AssemblyScript-related. Also he doesn't mention that wasm is faster to parse than JS. I'd be interested in a comparison of JS and wasm from the POV of a UI-heavy, compute-light app.
- pornel 4y ago
  While just the parsing step may be faster indeed, I don't think that aspect alone is enough to make a difference for an application. Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. In JS first run goes through an interpreter (without a delay for compilation/optimization), so JS has a pretty low latency for initial execution. JS is relatively easy to split into pieces and lazy load (there are various bundlers that support "chunking"), and not loading code is faster than fastest parsers. WASM could theoretically do that too, but current languages and tooling are more geared towards monolithic executables. For UI, where time to interactive matters most, JS will likely do a better than a big blob of WASM. WASM still needs to call out to JS for DOM interactions, so if your UI is DOM-based, you'll need a bunch of JS anyway, and have JS<>WASM communication overhead.
  - jagged-chisel 4y ago
    Does wasm support anything other than monolithic executables? The last I used it, multiple wasm bundles had to be loaded up by JavaScript and glued together with JavaScript.
  - saagarjha 4y ago
    > Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. You sure? Just figuring out what to call us going to typically require full parsing to find identifiers, scoping, etc.
    - Leszek 4y ago
      Browsers do a fast partial parse to figure out things like scoping and variable names, but skip actually building an AST so it's still a lot quicker than full parsing (e.g. https://v8.dev/blog/preparser https://v8.dev/blog/preparser)
- game-of-throws 4y ago
  js-framework-benchmark is the standard benchmark for UI-heavy, compute-light JS. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... To see results, show "vanillajs-1" and "wasm-bindgen", then hide everything else. WASM is about 6% slower, 18% longer startup, and 66% more memory usage. Note this is a UI benchmark so the results are overwhelmingly dominated by DOM interop. Things should improve if the WASM interface types proposal ever lands.
  - RobbieGM 4y ago
    I get that it would have a startup cost but I'm shocked that it uses more memory. Everyone complains about what a memory hog electron apps are and I assumed it was because of JS. But maybe we need something other than micro benchmarks to compare.
    - game-of-throws 4y ago
      The absolute numbers aren't that different. You need 100s of MB just to display an empty Chrome window. Then the 66% is the difference excluding that baseline, e.g. it might be 300MB to load Chrome, then you measure 301MB vs 301.66MB. I guess that might be a bit misleading. I think the electron memory usage comes down to the massive HTML spec and bloated old browser codebases. It's not JS. Node+V8 doesn't have nearly the memory usage of Chrome+V8.
      - RobbieGM 4y ago
        That difference is what I'd be interested in anyway as a developer who focuses on PWAs (where the cost of chrome is paid for already). I'm trying to work out whether a WASM stack would help runtime performance, memory usage, and startup time, but based on these numbers it doesn't look so inspiring.
RL_Quine 4y ago
The combination of colors and fonts makes this nearly impossible to read.
- wizofaus 4y ago
  Really? Aside from the dark red links on dark blue background, I couldn't disagree more - it's a rare example where picking custom colours for text & background really does work nicely.
syrusakbary 4y ago
I loved reading this article, I think it showcases pretty well that any optimization is about tradeoffs and there are hardly any absolutes. The article was also posted in HN about a year ago: https://news.ycombinator.com/item?id=26803155 https://news.ycombinator.com/item?id=26803155
moralestapia 4y ago
Very nice and well researched article. I'm all in on Wasm on the medium-to-long term as I think it will eventually dominate everything (embedded, mobile and web). The comparison with JS is a bit unfair as the former has had a 20+ year head start plus billions of dollars (yes, billions) in R&D to make it as performant as possible. I think JS is a great language/platform and I consider V8 an amazing piece of engineering, it would be on my list for the seven wonders of the digital world. Wasm will get there someday and will take the place of JS, IMO.
- dcow 4y ago
  We use WASM today and it's not for any performance reasons. Hopefully, like you say that will become an advantage too down the road as WASM matures. But, simply, there are parts of our application which we feel much more comfortable with and we find much more manageable being implemented in Rust and compiled to WASM. So for us WASM grants portability and language choice in a first class manner (as opposed to transpiling to and from JS and all the glue that entails). It's a real shot at dismantling the browser JS hegemony.
  - thebeastie 4y ago
    It sounds more like Rust gave you that choice, because it would have been just as good if the rust code transpiled to JS. I’m not knocking WASM just pointing out that you’re not praising any particular qualities of WASM, but of Rust.
    - moralestapia 4y ago
      >It sounds more like Rust gave you that choice Yes, but there's also a reason why the Rust -> JS route never took off. Wasm is positioning itself as the common runtime for a lot of frontends (term borrowed from LLVM). You could see it as some sort of spiritual successor to the JVM, and it may actually accomplish the goal of "Write once, run anywhere" to a much greater extent. (Btw, I am not criticizing Java here, I've worked with it and the JVM and other derivative languages for almost a decade and they all are quite valuable tools!)
svnpenn 4y ago
Personally Ive never cared about the performance aspect. If you care about that, you probably shouldn't be targetting the browser in the first place, but instead a native app. What has always turned me off about WASM, is that all the tutorials Ive read say you need some kind of JavaScript shim to get it working. That doesn't feel like a first class solution to me. If I can do WASM without any JavaScript, then I am interested.
- Animats 4y ago
  Everything has to be in the browser now. People don't download and run programs any more. Even if they want to, the programs have to be approved by Master Control. Apple [1] and Microsoft [2] are gradually tightening the restrictions for installing an executable on their platform. Downloading a program and installing it is now called "sideloading". Even for desktops. [1] https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/ [2] https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies https://docs.microsoft.com/en-us/windows/uwp/publish/store-p...
  - svnpenn 4y ago
    > Everything has to be in the browser now I have about 20 exe in a folder that say you're wrong. I also have about 9 other folders with unzipped programs that say you're wrong. Nothing is stopping anyone from downloading an executable file and running it on a desktop computer. Nor should it. How do you think people do software development? Or do you just think new programs come from magic pixie dust?
    - r_hoods_ghost 4y ago
      "Nothing is stopping anyone from downloading an executable file and running it on a desktop computer." Have you ever had a job? If you're in a workplace you probably don't have admin rights to install software on your desktop unless you are a dev, and even then it's not exactly guaranteed.
      - 4y ago
andsoitis 4y ago
> custom compiler for a TypeScript-like language targeting WebAssembly. The reason I like AssemblyScript (or ASC for short) is because it allows the average web developer to make use of WebAssembly without having to learn a potentially new language like C++ or Rust. It’s important to note that the language is TypeScript-like. Don’t expect your existing TypeScript code to just compile out of the box. That being said, the language is intentionally mirroring the behaviors and semantics of TypeScript (and therefore JavaScript), which means that the act of “porting” TypeScript to AssemblyScript are often mostly cosmetic, usually just adding type annotations. I haven't had the time to read more, but I'd be curious to learn why they didn't just target full TypeScript compatibility. That would reduce the barrier to entry materially.
- pohl 4y ago
  With TypeScript being a strict superset of JavaScript, wouldn't that entail dragging all of JavaScript semantics along?
  - andsoitis 4y ago
    > entail dragging all of JavaScript semantics along? They say: "... the language is intentionally mirroring the behaviors and semantics of TypeScript (and therefore JavaScript) " And then: "... which means that the act of “porting” TypeScript to AssemblyScript are often mostly cosmetic, usually just adding type annotations."
labrador 4y ago
The way I understand it, WebAssembly is faster because you skip the parsing of JavaScript. If parsing JavaScript is not a bottleneck in your app, it's not going to be faster. I'm also under the impression that people want it because they can use a language other than JavaScript. I could be wrong, but that's my going by 60 mph, looking out the window view
- tines 4y ago
  Not quite; if this were true then any javascript would be valid webassembly, which isn't the case.
  - labrador 4y ago
    I was excluding the parts of JavaScript that don't compile to WebAssembly, dom manipulation for example
    - aboodman 4y ago
      No parts of JavaScript compile to WebAssembly.
      - labrador 4y ago
        Interesting. That was a out-of-date misunderstanding on my part. I thought it was a binary JS AST. Thanks for the comment instead of just a negative vote https://yoric.github.io/post/binary-ast-newsletter-1/ https://yoric.github.io/post/binary-ast-newsletter-1/
dktoao 4y ago
Looking to get the perspective of some HN'ers here. I am primarily an embedded engineer working with C. Our (small) software team also has a few web people that work on the web UI of our embedded Linux product. Obviously, there is a ton of potential for shared code between the two products utilizing WASM. I recently ported one of our C libraries to WASM as an experiment with emscripten and was blown away by how easy it was. I can't run the unit tests in the browser yet but it seems to have worked perfectly. However, the JS "glue" code that is produced by the emscripten compiler is really scary looking, and as I understand is basically an abridged C runtime that needs to run in the browser. My questions are therefore: 1) Is it too early to adopt WASM for production use in a small company with limited resources? 2) If we did decide to go all in on WASM, what sort of gotchas might we be dealing with? Thanks everyone!
- cogman10 4y ago
  > Is it too early to adopt WASM for production use in a small company with limited resources? It really depends on what you are doing with it. For things like "I've got this C lib that I want to be able to call from the web" it's probably fine. For things like "I want to write my whole webpage in wasm" it's not ready for that (and, frankly, likely never will be). It's a matter of finding the right fit. > If we did decide to go all in on WASM, what sort of gotchas might we be dealing with? Depends on what you mean by "all in" if you mean, "I want ALL my webapp logic to live in wasm" then the biggest gotcha you'll face is shipping stuff into and out of the VM (including DOM elements) is really painful. IMO, UX continues to best be done with Javascript or compile to javascript langauges (typescript, for example). Using a language like C, C++, or Rust to do UX work will simply not be pleasant, will be hard to hire for, and will complicate a lot of your build system. Now, if by all in you mean "This logic only lives in this library and we are shipping that out as a WASM module" then I think wasm will work well there. Better, in fact, than other options like kotlin to native or J2CL (IMO). That said, there are fledgling UX frameworks written entirely for WASM. However, they are all relatively young and AFAIK, not exactly well established. This becomes an engineering decision and balancing act that I don't think can be 100% answered for your company.
  - 4y ago
modeless 4y ago
It's hard to beat JavaScript because the VMs are amazing. If you know a few tricks, like how to let the VM know you want integer math [1], you can get performance that's not too far off from native C in many cases. If you have a JavaScript application with a few hot functions that are slow, optimizing the JavaScript usually makes more sense than reaching for WASM. [1] https://james.darpinian.com/blog/integer-math-in-javascript https://james.darpinian.com/blog/integer-math-in-javascript
- solardev 4y ago
  > If you know a few tricks, like how to let the VM know you want integer math [1] > [1] Add | 0 after every math operation to get a 32-bit signed integer result, and >>> 0 for a 32-bit unsigned integer result. That's definitely gonna cause a few "wtf?" moments for everyone else on your team, lol
  - modeless 4y ago
    Yeah, you shouldn't do it all over the place prophylactically. It's a technique for optimizing functions that are performance critical. Although I find `| 0` surprisingly well known these days. I sometimes use it in places where I want a cast to integer.
- zinekeller 4y ago
  Most of those optimizations stems from Mozilla's asm.js (http://asmjs.org/ http://asmjs.org/), which specified those as an explicit signal. Note that if you're still supporting IE (commiserations and I wish you that you could decommission it ASAP) this will slow down you code (only in IE of course) instead of speeding it up.
- josephg 4y ago
  In my experience the place wasm really shines is in implementing custom data structures. A wasm b-tree, skip list, rope, etc seems to outperform the equivalent javascript code by many times. Edit: I just whipped up a real benchmark to test this, replaying some text editing traces[1]. Replaying the automerge-perf editing trace in javascript naively takes 610ms. Using a javascript based skip list it takes 77ms[2]. In native rust, with a rust port of the same skip list code I can process the same editing trace in 6ms[3]. Or 20ms when that rust code is compiled to wasm. So in this case, we're seeing about a 4x performance improvement using wasm, or 13x performance improvement using native code. [1] https://github.com/josephg/crdt-benchmarks https://github.com/josephg/crdt-benchmarks [2] This code https://gist.github.com/josephg/bcb2e74e52dc9c4651249fdffc48d1cf https://gist.github.com/josephg/bcb2e74e52dc9c4651249fdffc48... using this library: https://www.npmjs.com/package/jumprope https://www.npmjs.com/package/jumprope [3] https://crates.io/crates/jumprope https://crates.io/crates/jumprope
Georgelemental 4y ago
I think this is the first interrobang (‽) I've seen in the wild
wylie 4y ago
A group of smart WebAssembly experts tried to start a company around the idea of incrementally porting to WebAssembly, and wrote an excellent post-mortem of why that didn't work: https://zaplib.com/docs/blog_post_mortem.html https://zaplib.com/docs/blog_post_mortem.html
- tra3 4y ago
  That was interesting to read. Apart from wasm/rust experiment, they got real customers and validated their idea in the real world. Still an amazing result.
psyc 4y ago
Performance is important, but the point of WebAsm was to have an asm for other languages to compile to in the first place, so we could finally stop making embarrassing utterances like “JavaScript is the assembly language of the Web.”
pedalpete 4y ago
I think there are probably very few web environments that require webassembly, but we use it extensively at https://ayvri.com https://ayvri.com Gaming and other graphic intensive or computationally expensive apps are probably the best use case.
thealig 4y ago
interesting writeup, and detailed examples. i was wondering about the use case, from what little i've read, assemblyscript is an alternative for devs who want to stick to typescript style language with some fine grained control for lower level webassembly. see some utility for niche cases where perfor mance is needed for complex data structures, not entirely convinced though, specially with v8 JS giving excellent performace out of the box
benreesman 4y ago
Obviously you’re going to lose some performance. But it’s fucking fast, faster than anyone (including me) would have believed a few years ago. The ability to live-update software before the native code can arrive is a game-changer. This stuff is a big deal.

dvh 4y ago

How does it compare with canvas' blur filter, or boxblur canvas library?

He makes a point of showing how hard it is to achieve the same performance as JS with wasm, but the majority of the problems he runs into are AssemblyScript-related. Also he doesn't mention that wasm is faster to parse than JS. I'd be interested in a comparison of JS and wasm from the POV of a UI-heavy, compute-light app.

pornel 4y ago
While just the parsing step may be faster indeed, I don't think that aspect alone is enough to make a difference for an application. Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. In JS first run goes through an interpreter (without a delay for compilation/optimization), so JS has a pretty low latency for initial execution. JS is relatively easy to split into pieces and lazy load (there are various bundlers that support "chunking"), and not loading code is faster than fastest parsers. WASM could theoretically do that too, but current languages and tooling are more geared towards monolithic executables. For UI, where time to interactive matters most, JS will likely do a better than a big blob of WASM. WASM still needs to call out to JS for DOM interactions, so if your UI is DOM-based, you'll need a bunch of JS anyway, and have JS<>WASM communication overhead.
- jagged-chisel 4y ago
  Does wasm support anything other than monolithic executables? The last I used it, multiple wasm bundles had to be loaded up by JavaScript and glued together with JavaScript.
- saagarjha 4y ago
  > Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time. You sure? Just figuring out what to call us going to typically require full parsing to find identifiers, scoping, etc.
  - Leszek 4y ago
    Browsers do a fast partial parse to figure out things like scoping and variable names, but skip actually building an AST so it's still a lot quicker than full parsing (e.g. https://v8.dev/blog/preparser https://v8.dev/blog/preparser)
game-of-throws 4y ago
js-framework-benchmark is the standard benchmark for UI-heavy, compute-light JS. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... To see results, show "vanillajs-1" and "wasm-bindgen", then hide everything else. WASM is about 6% slower, 18% longer startup, and 66% more memory usage. Note this is a UI benchmark so the results are overwhelmingly dominated by DOM interop. Things should improve if the WASM interface types proposal ever lands.
- RobbieGM 4y ago
  I get that it would have a startup cost but I'm shocked that it uses more memory. Everyone complains about what a memory hog electron apps are and I assumed it was because of JS. But maybe we need something other than micro benchmarks to compare.
  - game-of-throws 4y ago
    The absolute numbers aren't that different. You need 100s of MB just to display an empty Chrome window. Then the 66% is the difference excluding that baseline, e.g. it might be 300MB to load Chrome, then you measure 301MB vs 301.66MB. I guess that might be a bit misleading. I think the electron memory usage comes down to the massive HTML spec and bloated old browser codebases. It's not JS. Node+V8 doesn't have nearly the memory usage of Chrome+V8.
    - RobbieGM 4y ago
      That difference is what I'd be interested in anyway as a developer who focuses on PWAs (where the cost of chrome is paid for already). I'm trying to work out whether a WASM stack would help runtime performance, memory usage, and startup time, but based on these numbers it doesn't look so inspiring.

RL_Quine 4y ago

The combination of colors and fonts makes this nearly impossible to read.

wizofaus 4y ago
Really? Aside from the dark red links on dark blue background, I couldn't disagree more - it's a rare example where picking custom colours for text & background really does work nicely.

syrusakbary 4y ago

I loved reading this article, I think it showcases pretty well that any optimization is about tradeoffs and there are hardly any absolutes. The article was also posted in HN about a year ago: https://news.ycombinator.com/item?id=26803155 https://news.ycombinator.com/item?id=26803155

moralestapia 4y ago

Very nice and well researched article. I'm all in on Wasm on the medium-to-long term as I think it will eventually dominate everything (embedded, mobile and web). The comparison with JS is a bit unfair as the former has had a 20+ year head start plus billions of dollars (yes, billions) in R&D to make it as performant as possible. I think JS is a great language/platform and I consider V8 an amazing piece of engineering, it would be on my list for the seven wonders of the digital world. Wasm will get there someday and will take the place of JS, IMO.

dcow 4y ago
We use WASM today and it's not for any performance reasons. Hopefully, like you say that will become an advantage too down the road as WASM matures. But, simply, there are parts of our application which we feel much more comfortable with and we find much more manageable being implemented in Rust and compiled to WASM. So for us WASM grants portability and language choice in a first class manner (as opposed to transpiling to and from JS and all the glue that entails). It's a real shot at dismantling the browser JS hegemony.
- thebeastie 4y ago
  It sounds more like Rust gave you that choice, because it would have been just as good if the rust code transpiled to JS. I’m not knocking WASM just pointing out that you’re not praising any particular qualities of WASM, but of Rust.
  - moralestapia 4y ago
    >It sounds more like Rust gave you that choice Yes, but there's also a reason why the Rust -> JS route never took off. Wasm is positioning itself as the common runtime for a lot of frontends (term borrowed from LLVM). You could see it as some sort of spiritual successor to the JVM, and it may actually accomplish the goal of "Write once, run anywhere" to a much greater extent. (Btw, I am not criticizing Java here, I've worked with it and the JVM and other derivative languages for almost a decade and they all are quite valuable tools!)

svnpenn 4y ago

Personally Ive never cared about the performance aspect. If you care about that, you probably shouldn't be targetting the browser in the first place, but instead a native app. What has always turned me off about WASM, is that all the tutorials Ive read say you need some kind of JavaScript shim to get it working. That doesn't feel like a first class solution to me. If I can do WASM without any JavaScript, then I am interested.

Animats 4y ago
Everything has to be in the browser now. People don't download and run programs any more. Even if they want to, the programs have to be approved by Master Control. Apple [1] and Microsoft [2] are gradually tightening the restrictions for installing an executable on their platform. Downloading a program and installing it is now called "sideloading". Even for desktops. [1] https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/ [2] https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies https://docs.microsoft.com/en-us/windows/uwp/publish/store-p...
- svnpenn 4y ago
  > Everything has to be in the browser now I have about 20 exe in a folder that say you're wrong. I also have about 9 other folders with unzipped programs that say you're wrong. Nothing is stopping anyone from downloading an executable file and running it on a desktop computer. Nor should it. How do you think people do software development? Or do you just think new programs come from magic pixie dust?
  - r_hoods_ghost 4y ago
    "Nothing is stopping anyone from downloading an executable file and running it on a desktop computer." Have you ever had a job? If you're in a workplace you probably don't have admin rights to install software on your desktop unless you are a dev, and even then it's not exactly guaranteed.
    - 4y ago

andsoitis 4y ago

> custom compiler for a TypeScript-like language targeting WebAssembly. The reason I like AssemblyScript (or ASC for short) is because it allows the average web developer to make use of WebAssembly without having to learn a potentially new language like C++ or Rust. It’s important to note that the language is TypeScript-like. Don’t expect your existing TypeScript code to just compile out of the box. That being said, the language is intentionally mirroring the behaviors and semantics of TypeScript (and therefore JavaScript), which means that the act of “porting” TypeScript to AssemblyScript are often mostly cosmetic, usually just adding type annotations. I haven't had the time to read more, but I'd be curious to learn why they didn't just target full TypeScript compatibility. That would reduce the barrier to entry materially.

pohl 4y ago
With TypeScript being a strict superset of JavaScript, wouldn't that entail dragging all of JavaScript semantics along?
- andsoitis 4y ago
  > entail dragging all of JavaScript semantics along? They say: "... the language is intentionally mirroring the behaviors and semantics of TypeScript (and therefore JavaScript) " And then: "... which means that the act of “porting” TypeScript to AssemblyScript are often mostly cosmetic, usually just adding type annotations."

labrador 4y ago

The way I understand it, WebAssembly is faster because you skip the parsing of JavaScript. If parsing JavaScript is not a bottleneck in your app, it's not going to be faster. I'm also under the impression that people want it because they can use a language other than JavaScript. I could be wrong, but that's my going by 60 mph, looking out the window view

tines 4y ago
Not quite; if this were true then any javascript would be valid webassembly, which isn't the case.
- labrador 4y ago
  I was excluding the parts of JavaScript that don't compile to WebAssembly, dom manipulation for example
  - aboodman 4y ago
    No parts of JavaScript compile to WebAssembly.
    - labrador 4y ago
      Interesting. That was a out-of-date misunderstanding on my part. I thought it was a binary JS AST. Thanks for the comment instead of just a negative vote https://yoric.github.io/post/binary-ast-newsletter-1/ https://yoric.github.io/post/binary-ast-newsletter-1/

dktoao 4y ago

Looking to get the perspective of some HN'ers here. I am primarily an embedded engineer working with C. Our (small) software team also has a few web people that work on the web UI of our embedded Linux product. Obviously, there is a ton of potential for shared code between the two products utilizing WASM. I recently ported one of our C libraries to WASM as an experiment with emscripten and was blown away by how easy it was. I can't run the unit tests in the browser yet but it seems to have worked perfectly. However, the JS "glue" code that is produced by the emscripten compiler is really scary looking, and as I understand is basically an abridged C runtime that needs to run in the browser. My questions are therefore: 1) Is it too early to adopt WASM for production use in a small company with limited resources? 2) If we did decide to go all in on WASM, what sort of gotchas might we be dealing with? Thanks everyone!

cogman10 4y ago
> Is it too early to adopt WASM for production use in a small company with limited resources? It really depends on what you are doing with it. For things like "I've got this C lib that I want to be able to call from the web" it's probably fine. For things like "I want to write my whole webpage in wasm" it's not ready for that (and, frankly, likely never will be). It's a matter of finding the right fit. > If we did decide to go all in on WASM, what sort of gotchas might we be dealing with? Depends on what you mean by "all in" if you mean, "I want ALL my webapp logic to live in wasm" then the biggest gotcha you'll face is shipping stuff into and out of the VM (including DOM elements) is really painful. IMO, UX continues to best be done with Javascript or compile to javascript langauges (typescript, for example). Using a language like C, C++, or Rust to do UX work will simply not be pleasant, will be hard to hire for, and will complicate a lot of your build system. Now, if by all in you mean "This logic only lives in this library and we are shipping that out as a WASM module" then I think wasm will work well there. Better, in fact, than other options like kotlin to native or J2CL (IMO). That said, there are fledgling UX frameworks written entirely for WASM. However, they are all relatively young and AFAIK, not exactly well established. This becomes an engineering decision and balancing act that I don't think can be 100% answered for your company.
- 4y ago

modeless 4y ago

It's hard to beat JavaScript because the VMs are amazing. If you know a few tricks, like how to let the VM know you want integer math [1], you can get performance that's not too far off from native C in many cases. If you have a JavaScript application with a few hot functions that are slow, optimizing the JavaScript usually makes more sense than reaching for WASM. [1] https://james.darpinian.com/blog/integer-math-in-javascript https://james.darpinian.com/blog/integer-math-in-javascript

solardev 4y ago
> If you know a few tricks, like how to let the VM know you want integer math [1] > [1] Add | 0 after every math operation to get a 32-bit signed integer result, and >>> 0 for a 32-bit unsigned integer result. That's definitely gonna cause a few "wtf?" moments for everyone else on your team, lol
- modeless 4y ago
  Yeah, you shouldn't do it all over the place prophylactically. It's a technique for optimizing functions that are performance critical. Although I find `| 0` surprisingly well known these days. I sometimes use it in places where I want a cast to integer.
zinekeller 4y ago
Most of those optimizations stems from Mozilla's asm.js (http://asmjs.org/ http://asmjs.org/), which specified those as an explicit signal. Note that if you're still supporting IE (commiserations and I wish you that you could decommission it ASAP) this will slow down you code (only in IE of course) instead of speeding it up.
josephg 4y ago
In my experience the place wasm really shines is in implementing custom data structures. A wasm b-tree, skip list, rope, etc seems to outperform the equivalent javascript code by many times. Edit: I just whipped up a real benchmark to test this, replaying some text editing traces[1]. Replaying the automerge-perf editing trace in javascript naively takes 610ms. Using a javascript based skip list it takes 77ms[2]. In native rust, with a rust port of the same skip list code I can process the same editing trace in 6ms[3]. Or 20ms when that rust code is compiled to wasm. So in this case, we're seeing about a 4x performance improvement using wasm, or 13x performance improvement using native code. [1] https://github.com/josephg/crdt-benchmarks https://github.com/josephg/crdt-benchmarks [2] This code https://gist.github.com/josephg/bcb2e74e52dc9c4651249fdffc48d1cf https://gist.github.com/josephg/bcb2e74e52dc9c4651249fdffc48... using this library: https://www.npmjs.com/package/jumprope https://www.npmjs.com/package/jumprope [3] https://crates.io/crates/jumprope https://crates.io/crates/jumprope

Georgelemental 4y ago

I think this is the first interrobang (‽) I've seen in the wild

wylie 4y ago

A group of smart WebAssembly experts tried to start a company around the idea of incrementally porting to WebAssembly, and wrote an excellent post-mortem of why that didn't work: https://zaplib.com/docs/blog_post_mortem.html https://zaplib.com/docs/blog_post_mortem.html

tra3 4y ago
That was interesting to read. Apart from wasm/rust experiment, they got real customers and validated their idea in the real world. Still an amazing result.

psyc 4y ago

Performance is important, but the point of WebAsm was to have an asm for other languages to compile to in the first place, so we could finally stop making embarrassing utterances like “JavaScript is the assembly language of the Web.”

pedalpete 4y ago

I think there are probably very few web environments that require webassembly, but we use it extensively at https://ayvri.com https://ayvri.com Gaming and other graphic intensive or computationally expensive apps are probably the best use case.

thealig 4y ago

interesting writeup, and detailed examples. i was wondering about the use case, from what little i've read, assemblyscript is an alternative for devs who want to stick to typescript style language with some fine grained control for lower level webassembly. see some utility for niche cases where perfor mance is needed for complex data structures, not entirely convinced though, specially with v8 JS giving excellent performace out of the box

benreesman 4y ago

Obviously you’re going to lose some performance. But it’s fucking fast, faster than anyone (including me) would have believed a few years ago. The ability to live-update software before the native code can arrive is a game-changer. This stuff is a big deal.