WebAssembly Target

(Matt Lord) #1

Does anyone know what the main blockers are to getting a WebAssembly target building and running using the wasm32-unknown-unknown toolchain?

I’m really interested in being able to make a game that I can export to Native and Web.

Thanks

1 Like

Creating games as revenue-generators
(Théo Degioanni) #2

Hello! Here’s a couple of them, without any specific order:

  • gfx-hal’s WebGL support
  • winit?
  • support for file systems
  • support for WebAssembly threads in browsers (!!)
2 Likes

(Erlend Sogge Heggen) #3

Getting closer!

1 Like

(Erlend Sogge Heggen) #4

https://github.com/fitzgen/rfcs-1/blob/2019-roadmap/text/000-2019-roadmap.md#multithreading-for-wasm

Our toolchain already has experimental support for multithreading in Wasm. Browsers are currently shipping SharedArrayBuffer and atomics (the primitives of multithreading for Wasm) behind feature flags, and they expect to start shipping them enabled by default in 2019.

One of WebAssembly’s selling points is the ability to effectively utilize available hardware. Multithreading extends that story from a single core to many. While multithreading will be literally possible for both JavaScript and any compiled-to-Wasm language, Rust’s unique ownership system makes it economically realistic .

There are some technical snags (see the link above for details) that mean we can’t get Rust’s standard library’s std::thread::* working on Wasm. But it is still crucial that we have shared implementations of core multithreading building blocks like thread pools and locks across the ecosystem. In 2019, we should transform our experimental multithreading support into a production-ready foundation for multithreading on Wasm, get popular crates like rayon working on the Web, and cash in on Rust’s fearless concurrency.

1 Like

(Erlend Sogge Heggen) #5

We’ve received funding for WASM development so expect steady progress here shortly.

https://amethyst.rs/blog/moss-grant-announce/

1 Like