h1 WASM 2019
- 2019-01-15

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.

Status quo

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.

fn main

The narrative of the WASM WG’s tooling in 2018 has mostly revolved around allowing people building browser applications to gradually introduce Rust into their workflows. This has been great for people looking to improve parts of their existing JavaScript codebase.

I’d like Rust’s WASM story to focus on building an integrated experience this year. Even though WASM is not intended to replace JavaScript, I think we can learn a lot by pushing WASM as far as we can by itself. I think this should give us insights in what is missing, and what needs improving, leading us to create a better Rust WASM experience for every workflow.

I think a good goal is to aim to add first-class support for standalone WASM binaries. Standalone meaning: the Rust code drives the application logic, rather than having JavaScript call into Rust library functions.

For example [wasm_bindgen(start)] 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 cargo run.

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.

Keep polishing

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-bindgen doesn’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.

Wrapping up

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.