Hacker News Reader

Comment by vlucas | Hacker News Reader

It's worth noting that the WASM package takes up 476kb shipped and the wasm.js loader is another ~25kb. So this bare-bones site is already sitting at > 500kb of JavaScript shipped to the client.

I am glad to see things like this are possible now with WASM, but there is a lot of room for improvement here that I hope gets captured by browser vendors over time.

View on HN

Just to clarify, 476kb of WebAssembly != 476kb of JavaScript. Still, your point stands in that wasm-based sites will likely never beat their pure JavaScript counterparts in terms of data transfer; you'll need to make up the increased cost of wasm somewhere else. One place that browsers attempt to make up the difference is in the use of streaming compilers, where the browser can start compiling wasm as it's coming in from the network, whereas with JavaScript browsers have to wait until the entire resource is delivered before the parsing stage can begin.

To expound on this difference: 476KB of WebAssembly loads like 476KB of images (that is, super fast) rather than like 476KB of JavaScript (which is pretty slow and blocks the main thread). https://hacks.mozilla.org/2018/01/making-webassembly-even-fa... explains more.

I could build his example in 2-3kb of vanilla JS unminified :)

Thank you for the explanation - I didn't know this about WebAssembly! I followed a link from another reply here and learned something new today.

luckily WebAssembly is stream compiled while data is being fetched in parallel; unlike JS it does not need to load the whole file to start working on it :)

Reply on news.ycombinator.com