Two days ago I wrote about what I plan to work on this year. This is my post about what I’d like to see happen with WebAssembly and Rust in 2019.
2018 has been a really cool year for WASM and Rust. Back in February the WASM toolchain became usable. Around the same time both wasm-bindgen and wasm-pack were kicked off (I remember the dates because of this gem).
I think it’s interesting to point this out, because it means that at the time of writing Rust’s defacto WASM toolchain is about 9 months old. That’s not a long time for a project that is now considered standard. It’s super impressive how much the WASM WG has accomplished last year!
Let’s take a look at what might be possible to accomplish this year.
can be used as an application entry point, and the resulting binaries can be
served with a static web server. But neither of them feel as nice as Rust’s own
fn main and
Build an ecosystem
Speaking of ecosystems, we should probably build one! There’s a few points I think are important:
- Don’t create branded silos. Branding might perhaps be useful to achieve fame. But if we truly want Rust’s WASM story to succeed we should think of ways to collaborate instead of carving out territory.
- Centralize discovery. We’re trying to build an ecosystem from scratch. Having a place where module authors can share their results will likely allow us to coordinate without much overhead. Something that for example might work is for the WASM WG to create an awesome list under the GitHub org, and liberally accepting contributions.
- Encourage experimentation. I think it’s way too early in Rust’s lifecycle to know what the right way is to do things. Even more so for Rust WASM. I think we should encourage experimentation and sharing results early. The lower we can make the boundary to experiment, the likelier it is that people will get involved, and in turn the likelier the ecosystem will grow in both size and quality.
This is the “miscellaneous” part of my post. There’s some things I’ve noticed that are missing, or I wish we had in no particular order:
wasm-bindgendoesn’t generate source maps yet. Having them would be excellent for debugging.
- The story around async and WASM seems only partly executed so far. Rust Futures can be converted to JS Promises and hooked into the JS event loop, but running your own multi-threaded loop seems to involve a lot of manual work still.
- Rust WASM artifacts are single binaries which are hard to cache and incrementally load. There’s probably exploration possible around code splitting and dynamically loading.
- Setting up a WASM project requires quite some boilerplate. It’d be nice if we could find ways to reduce this.
- Passing errors to and from JS isn’t as smooth as it could be.
And that’s more or less what I’d like to see from Rust WASM this year. I feel Rust’s WASM story is very much on the right patch already, and I hope this will only keep improving in 2019.
I hope this has been useful. Thanks for reading!