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... :/
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.
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!
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 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.
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.)
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).
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.
"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.
> 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.
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... :/