4 ms·

You need to use the script for release mode. $> wasm-pack build --target no-modules --release -- --features "wee_alloc" It will shrink it down to 165KB

K0nserv 7y ago
Doh. My bad for being a dummy. 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-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...
- ivanceras 7y ago
  I think If you start adding more code, the growth of the release binary will diminish. The todomvc code is only 207KB when compiled and has relatively more code than the minimal example. 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.
- wyldfire 7y ago
  > EDIT: It's 68KB gzipped and 165KB is the uncompressed size 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?
- steveklabnik 7y ago
  https://github.com/rustwasm/twiggy https://github.com/rustwasm/twiggy
- ppseafield 7y ago
  On top of that it's still pretty favorable compared to other web framework sizes.
- tiuPapa 7y ago
  I think you can still reduce that size further with binaryen
- stjohnswarts 7y ago
  168k is nothing, that's less than an image by the standards of many web elements these days.
  - structural 7y ago
    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.
    - paulddraper 7y ago
      jQuery is 84KB. react + react-dom is 109KB. Bootstrap 4 is 187KB. Par for the course
  - K0nserv 7y ago
    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.

K0nserv 7y ago

Doh. My bad for being a dummy. 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-faster-firefoxs-new-streaming-and-tiering-compiler/ https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

ivanceras 7y ago
I think If you start adding more code, the growth of the release binary will diminish. The todomvc code is only 207KB when compiled and has relatively more code than the minimal example. 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.
wyldfire 7y ago
> EDIT: It's 68KB gzipped and 165KB is the uncompressed size 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?
steveklabnik 7y ago
https://github.com/rustwasm/twiggy https://github.com/rustwasm/twiggy
ppseafield 7y ago
On top of that it's still pretty favorable compared to other web framework sizes.
tiuPapa 7y ago
I think you can still reduce that size further with binaryen
stjohnswarts 7y ago
168k is nothing, that's less than an image by the standards of many web elements these days.
- structural 7y ago
  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.
  - paulddraper 7y ago
    jQuery is 84KB. react + react-dom is 109KB. Bootstrap 4 is 187KB. Par for the course
- K0nserv 7y ago
  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.