$> wasm-pack build --target no-modules --release -- --features "wee_alloc"
It will shrink it down to 165KB
$> wasm-pack build --target no-modules --release -- --features "wee_alloc"
It will shrink it down to 165KB
165kb is still fairly big for a minimal example, much smaller than 1.17MB though, compared to React for example. Are there ways to analyze what contributes to the size for WASM compiled projects? I guess wasm-bindgen contributes significantly to the size currently.
EDIT: It's 68KB gzipped and 165KB is the uncompressed size. One great benefit of WASM is that as described in "Making WebAssembly even faster: Firefox’s new streaming and tiering compiler"[0] it's much faster than JS to parse and execute.
0: https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
There is a lot of rust compilation flags, and I have only tested a few. I also enabled a lot of wasm-bindgen features in the library, I will eventually tighten it up.
What's the state of brotli content type support in browsers? Wasn't that supposed to be the next generation beyond gzip? Would it get a better still compression ratio? And FB is pushing zstd -- is that something that might be supported eventually?
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.
Par for the course
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.