Description
Describe the Bug
I'm new to Rust and WASM, and have been using this template to learn both. As my project grew, so did my build times, but Rust has a reputation for slower compiles, so I didn't think very much of it.
Today I took some time to investigate improving build times and I was able to get a 7x improvement by running wasm-pack --target web and writing normal standard JS.
I understand that there are a lot of parts of the web ecosystem that need a bundler to work today (e.g. JSX), so this might be the right option for today. Might be worth investigating esbuild with a wasm supporting plugin though? Or add something to the README about how for projects that don't need much JS --target web can be a better option?
Or maybe there's a way to run webpack without requiring it to process the wasm? As far as I can tell the wasm runs fine without webpack doing anything to it...
Steps to Reproduce
- Check out https://github.com/rictic/airlock.chat at revision f22af3254c8a94a64e2249f75f28c428ab98ef27
- Run
./start.shto start webpack dev server and cargo watch to re-run wasm-pack on save. - Observe the speed of the edit-refresh loop (~12s on my machine).
- Compare that with an incremental rebuild of
wasm-pack --dev --target web(~1s on my machine)
Expected Behavior
The edit-refresh for a mostly-rust project is largely dependent on the speed of wasm-pack.
Actual Behavior
Most of the time is spent in webpack, and as the size of the emitted wasm file increases, time spent in webpack increases as well.
Additional Context
See rictic/airlock.chat#65 for more details of what went into moving one project off of using a bundler entirely (though it helps that it's almost entirely Rust, and as a little prototype it doesn't need to support older browsers).
Activity