It's still a lot given that when targetting the entire world (especially either mobile links or portions of the globe that don't have a CDN a millisecond away), a typical assumed link is on the order of 512 kbps bandwidth with 100ms RTT. That's two and a half seconds to load just your framework with a cold cache and without including any content.
Yes, many web developers are just targeting their own areas and test on high-speed links and everything seems fine, but frameworks that aim for widespread use still need to care about every single byte.
Images are not comparable to WASM and especially not to JS. This is described in "Making WebAssembly even faster: Firefox’s new streaming and tiering compile", but the TL;DR is that network is less so the bottleneck than parsing and execution these days.
Further the notion that 168kb is nothing is a bit sad when you consider emerging markets and other low bandwith/CPU scenarios. One of my hopes with WASM is that it can achieve both smaller bundles and better parse/execute performance. To my understanding one of the big blockers for this right now is the lack of a DOM API for WASM.
Comments
168k is nothing, that's less than an image by the standards of many web elements these days.
It's still a lot given that when targetting the entire world (especially either mobile links or portions of the globe that don't have a CDN a millisecond away), a typical assumed link is on the order of 512 kbps bandwidth with 100ms RTT. That's two and a half seconds to load just your framework with a cold cache and without including any content.
Yes, many web developers are just targeting their own areas and test on high-speed links and everything seems fine, but frameworks that aim for widespread use still need to care about every single byte.
jQuery is 84KB. react + react-dom is 109KB. Bootstrap 4 is 187KB.
Par for the course
Images are not comparable to WASM and especially not to JS. This is described in "Making WebAssembly even faster: Firefox’s new streaming and tiering compile", but the TL;DR is that network is less so the bottleneck than parsing and execution these days.
Further the notion that 168kb is nothing is a bit sad when you consider emerging markets and other low bandwith/CPU scenarios. One of my hopes with WASM is that it can achieve both smaller bundles and better parse/execute performance. To my understanding one of the big blockers for this right now is the lack of a DOM API for WASM.