| > It's the gzipped size that matters a lot more. Disagree. The bytes have to be read and extracted and the bigger it is, the more you are putting onto clients to load your page. I'd also point out that this doesn't appear to be just simple runtime stuff like I thought. The fact that there's a 2x size difference between a simple webpage and a simple todo blog indicates this might be quiet expensive. That doesn't bode well for more complex applications. I'd also point out that I just looked at the wasm. The bindings javascript themselves took up 37kb. That's bigger than react just for bindings. > A general website will likely need a lot more data in the form of images and other media so all in all this is not too bad. Yes, and a general website can function without those images. The part that makes the webpage functional is what I'm focusing on. > The reason why bundle size for JS is so important is that the browser needs to first download the JS, parse the JS, then JIT compile it before it can start running. For WASM on the other hand, the browser can in fact parse it while downloading in parallel and then run it almost immediately since WASM is much lower level. So for WASM the main bottleneck is downloading whereas JS, it is parsing and compiling. Before the browser can run a wasm blob, it has to download the javascript bindings which it has to parse and jit compile. It can be compiling the wasm while it's parsing the javascript, but it's not a free lunch. The wasm cannot start running until after the javascript is finished. The browser is also free to start parsing the javascript while it's being downloaded. There's nothing special about javascript syntax that stops a browser from starting parsing while it's in flight (other than it might end up being dead). |