7 ms·

Did you see the benchmarks? There's almost no difference between javascript and wasm except for a single certain browser. So you're really going to take on the

Did you see the benchmarks? There's almost no difference between javascript and wasm except for a single certain browser. So you're really going to take on the maintenance burden to get that better performance? This is a cool technique but I can just imagine the looks on my team mates faces when I tell them it isn't react... :/

nicoburns 8y ago
Weird that they didn't say which browser is which :/
- RivieraKid 8y ago
  Probably were worried it would look like they're trying to shame their business partners (Apple and Microsoft I guess).
  - acqq 8y ago
    Actually it seems that the second worst in JavaScript (when executing their example) is Chrome? User robko here https://news.ycombinator.com/item?id=19167078 https://news.ycombinator.com/item?id=19167078 measured the code on node.js, and node.js is based on Chrome's V8 and he measured 1.5 sec vs article author's of around 2.7s, so it would seem that robko has some almost twice as fast CPU, and the other two (fast) JavaScripts are under 500 ms, and the slowest is 8 seconds, so V8 of Chrome remains the only candidate for the second worst performing of their example.
    - om2 8y ago
      I wish they had at east posted a browser-runnable version of their test so we could see for ourselves which browser is which, or compare JS vs WASM on our own systems. (On this type of code, I'd expect Safari to be the fastest, not Chrome.)
      - acqq 8y ago
        See my "minimal" C++ translation in my other post here. There's not much to add. For JavaScript start with their code, but add the allocation, just replace allocations with var a = new Uint32Array(height * width); and b the same. Add the timing (1), put in HTML and you're done. It's easy, just a few minutes for anybody who works with that (and this site should be filled with the competent developers AFAIK). 1) https://developer.mozilla.org/en-US/docs/Web/API/Performance https://developer.mozilla.org/en-US/docs/Web/API/Performance
- fireattack 8y ago
  They said it in the article: >Note: Due to legal concerns, I won’t name any browsers in this article.
  - IshKebab 8y ago
    What legal concerns? Companies benchmark their competitors all the time.
    - onli 8y ago
      Yep. It's complete bullshit and it's a shame to see cowardice corporate legal fearmongering like this in a company like Google, that was once at the same wavelength as the technical/hacker community. As if Firefox, Microsoft or Apple would sue them for publishing one browser benchmark. Even worse if it were a pretext to not make Chrome look bad.
      - eridius 8y ago
        "Legal concerns" is a weird excuse, but personally, I'm glad they didn't name names. The point of this article isn't to shame any browser vendors, it's to talk about WebAssembly. Naming the browsers would have just distracted from the article's topic.
        onli 8y ago
        Would that be the explanation given it would be completely fine :)
ekc 8y ago
That's not true in almost any circumstance. What "benchmarks" are you referencing?
gbba 8y ago
Yes if it provides a better product for users.
bitwize 8y ago
There's got to be at least one RESF member on your team. You can sell the technique by telling them they get to use Rust in your web front end.
mnutt 8y ago
It isn't a rebuttal to this article, but I found this blog post about optimizing javascript to be really, really interesting: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
- markdog12 8y ago
  Don't forget to follow that up with the second follow-up: http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry....
writepub 8y ago
WASM's biggest claim to fame is providing web development access to non js devs. Having done C for a majority of my life, the ability to build and execute C code for large scale web deployment is appealing!
tom_mellior 8y ago
> There's almost no difference between javascript and wasm except for a single certain browser. For very large values of "single", approaching "two". In the "Speed comparison per language" chart, Browser 3 is more than 5x slower than Browser 2 on JavaScript/WASM, and Browser 4 is slower still. So there are very significant improvements on two out of the four browsers tested.
maeln 8y ago
We have to remember that the current WASM spec is still "just" a MVP. It doesn't yet include performance related spec (like SMID). WASM is also fairly recent. JS interpreter/JIT in browser has seen years of optimization with a trove of real world usage. It will take some time for WASM to be able to compete seriously. Another factor is also that the WASM compilers for various languages (Rust, C/C++, etc) are obviously recent too and not super optimized. My own tiny experiment is that WASM can already yield quite decent performance gain but with very compute intensive load, which is not a typical problem in frontend development. The size gain is also real, but you need to handcraft your WASM or forget about using the std and other stuff in the language you are compiling from (Rust generate very fat binary with a naïve implementation for example). Still, I am quite optimistic about WASM. I was actually impressed that, even though it is quite recent, I can already compete with JS when it come to performance. When the various performance-related spec will be finalized and implemented and that browsers and compilers start heavily optimizing the WASM, we should really see some real-world gain.

nicoburns 8y ago

Weird that they didn't say which browser is which :/

RivieraKid 8y ago
Probably were worried it would look like they're trying to shame their business partners (Apple and Microsoft I guess).
- acqq 8y ago
  Actually it seems that the second worst in JavaScript (when executing their example) is Chrome? User robko here https://news.ycombinator.com/item?id=19167078 https://news.ycombinator.com/item?id=19167078 measured the code on node.js, and node.js is based on Chrome's V8 and he measured 1.5 sec vs article author's of around 2.7s, so it would seem that robko has some almost twice as fast CPU, and the other two (fast) JavaScripts are under 500 ms, and the slowest is 8 seconds, so V8 of Chrome remains the only candidate for the second worst performing of their example.
  - om2 8y ago
    I wish they had at east posted a browser-runnable version of their test so we could see for ourselves which browser is which, or compare JS vs WASM on our own systems. (On this type of code, I'd expect Safari to be the fastest, not Chrome.)
    - acqq 8y ago
      See my "minimal" C++ translation in my other post here. There's not much to add. For JavaScript start with their code, but add the allocation, just replace allocations with var a = new Uint32Array(height * width); and b the same. Add the timing (1), put in HTML and you're done. It's easy, just a few minutes for anybody who works with that (and this site should be filled with the competent developers AFAIK). 1) https://developer.mozilla.org/en-US/docs/Web/API/Performance https://developer.mozilla.org/en-US/docs/Web/API/Performance
fireattack 8y ago
They said it in the article: >Note: Due to legal concerns, I won’t name any browsers in this article.
- IshKebab 8y ago
  What legal concerns? Companies benchmark their competitors all the time.
  - onli 8y ago
    Yep. It's complete bullshit and it's a shame to see cowardice corporate legal fearmongering like this in a company like Google, that was once at the same wavelength as the technical/hacker community. As if Firefox, Microsoft or Apple would sue them for publishing one browser benchmark. Even worse if it were a pretext to not make Chrome look bad.
    - eridius 8y ago
      "Legal concerns" is a weird excuse, but personally, I'm glad they didn't name names. The point of this article isn't to shame any browser vendors, it's to talk about WebAssembly. Naming the browsers would have just distracted from the article's topic.
      - onli 8y ago
        Would that be the explanation given it would be completely fine :)

ekc 8y ago

That's not true in almost any circumstance. What "benchmarks" are you referencing?

gbba 8y ago

Yes if it provides a better product for users.

bitwize 8y ago

There's got to be at least one RESF member on your team. You can sell the technique by telling them they get to use Rust in your web front end.

mnutt 8y ago

It isn't a rebuttal to this article, but I found this blog post about optimizing javascript to be really, really interesting: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...

markdog12 8y ago
Don't forget to follow that up with the second follow-up: http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry.html http://fitzgeraldnick.com/2018/02/26/speed-without-wizardry....

writepub 8y ago

WASM's biggest claim to fame is providing web development access to non js devs. Having done C for a majority of my life, the ability to build and execute C code for large scale web deployment is appealing!

tom_mellior 8y ago

> There's almost no difference between javascript and wasm except for a single certain browser. For very large values of "single", approaching "two". In the "Speed comparison per language" chart, Browser 3 is more than 5x slower than Browser 2 on JavaScript/WASM, and Browser 4 is slower still. So there are very significant improvements on two out of the four browsers tested.

maeln 8y ago

We have to remember that the current WASM spec is still "just" a MVP. It doesn't yet include performance related spec (like SMID). WASM is also fairly recent. JS interpreter/JIT in browser has seen years of optimization with a trove of real world usage. It will take some time for WASM to be able to compete seriously. Another factor is also that the WASM compilers for various languages (Rust, C/C++, etc) are obviously recent too and not super optimized. My own tiny experiment is that WASM can already yield quite decent performance gain but with very compute intensive load, which is not a typical problem in frontend development. The size gain is also real, but you need to handcraft your WASM or forget about using the std and other stuff in the language you are compiling from (Rust generate very fat binary with a naïve implementation for example). Still, I am quite optimistic about WASM. I was actually impressed that, even though it is quite recent, I can already compete with JS when it come to performance. When the various performance-related spec will be finalized and implemented and that browsers and compilers start heavily optimizing the WASM, we should really see some real-world gain.