You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
Run ./start.sh to 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).
The text was updated successfully, but these errors were encountered:
I also want to say that wasm-pack-template, wasm-pack, rust, and this entire cluster of tools and libraries have been super impressive, and besides this issue they've been a really great experience to work with.
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
./start.sh
to start webpack dev server and cargo watch to re-run wasm-pack on save.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).
The text was updated successfully, but these errors were encountered: