[chrismorgan]

You’re still missing much the point of the article: WASM isn’t for the browser only. WASI, for example, is a full environment you can run stuff in without any such interoperability cost.

But even inside something like Node.js or the browser, most of these sorts of benchmark attempts are of converting only small parts of a system, so that message passing or format shifting ends up a comparatively large fraction of the work being done. If you migrate as much as possible into WASM and treat JS as the foreign side rather than WASM, you will tend to find that there’s much less serialisation/deserialisation overhead in the performance-sensitive parts, because the data they needed was on the WASM side from the start, rather than having to be copied in from the JS side. (This is, of course, a simplifying generalisation.) A somewhat more conservative strategy is to still treat JS as the native side as WASM as foreign, but expand the WASM as far as necessary to reach a point where very little data interchange will be needed. What that is may vary enormously, and such a boundary doesn’t always exist.

[maga]

> You’re still missing much the point of the article: WASM isn’t for the browser only. WASI, for example, is a full environment you can run stuff in without any such interoperability cost.

Of course, but we are not arguing about the point of the article, I'm contesting the exact claim that "WebAssembly is almost always faster than JavaScript". Admittedly, not because it's such a big mistake on the author's part, but because I'm a bit irate with the usual flow of discussions about WebAssembly here on HN that take this claim for granted and regurgitate it incessantly. This is not the case for the mentioned reasons: data copying overhead and JS itself being compiled by JIT resulting in pretty performant code if well-optimized. Also, the comparison to JS only makes sense when we are talking about running both in the JS engine, not against a dedicated WASM runtime, otherwise it would be tantamount to arguing that Java is not faster than JS.

By the way, if someone really wants to dig into the issue I recommend an article from one of the V8 authors where he dissects one such WASN success story: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...

[cornstalks]

I think part of the pushback you're getting here is that you're contesting "WebAssembly is almost always faster than JavaScript" (which IMO is correct and appropriately couched) with "WASM + JS can be slower than just JS" (which is also correct), but the way you're communicating it comes across as "WASM is just slower than JS" (that's obviously not literally what you're saying, but that's how it's coming across).

If we're going to be pedantic and nit-picky about claims, please use more precise counterclaims. It only takes a few extra words to clearly state you're talking about WASM + JS, which is an important distinction since many† people here are interested in WASM-only, without the JS (with the alternative in their mind being JS-only, without the WASM).

†In the spirit of pedantry, I mean many. Not all. Maybe not even a majority. But reasonably many.

[jturpin]

> I'm a bit irate with the usual flow of discussions about WebAssembly here on HN that take this claim for granted and regurgitate it incessantly.

It is still more honest to regurgitate the claim that Wasm is faster than JS than to try and argue that "JS is about 10x faster than wasm in simple linear regression."