2019 roadmap

[fitzgen]

Rendered

[fitzgen]

Following the loose schedule we laid out for ourselves, we should hopefully come to consensus and merge this roadmap RFC by the end of February.

[svenstaro]

In the past, I've read some of you saying that you wanted to think about collaborating/integrating with stdweb in some ways. Is that still on the horizon?

[jgarvin]

I disagree with the premise that full Rust web apps are not a strong point (though I appreciate that everything proposed here will still help them). Part of the reason lots of projects have an eclectic language mix is because none of them are simultaneously good enough at all the things needed to make a great web application. Rust either is or can be good at all of them though. Static typing and borrow checker reliability and performance, but with great inference and the ability to sprinkle Rc when you don't want/need to think too hard.

[Pauan]

@svenstaro Yup: koute/stdweb#318

[gnzlbg]

Sad not to see running unit tests reliably in the Roadmap. wasm-bindgen-test should always work.

[jamii]

Is there currently any record of tooling performance? (https://perf.rust-lang.org/ is currently down so I can't see if there are wasm benchmarks there).

At the hello-world stage of the wasm book tutorial, the end-to-end latency (from hitting save in the editor to seeing changes in the browser) using npm run start and cargo watch 'web-pack build --debug' is around ~6s. Eyeballing from recorded video I get:

• ~0.3s for save/rustfmt
• ~1s before watch notices
• ~0.3s for build/bindgen
• ~3s for webpack recompile
• ~0.2s for page reload

(I realize that doesn't add up to 6s. It's a crude way to measure things.)

By building with no_modules and firing a script from the editor instead of using file-watching, I can get this down to 0.5s. The same method takes 1.1s for wasm-bindgen/examples/todo-mvc. That's faster than most javascript tooling, and possibly on par with clojurescripts live reloading (I get 0.6s using figwheel-main on a similar size app).

The main objection I've experienced when proposing rust/wasm is compile times, but the end-to-end latency actually looks pretty competitive so far, especially for no_modules setups. Having a couple of benchmarks in CI and a graph online somewhere would go a long way towards keeping it that way, even if pure rust apps are not a current focus.

[liamcurry]

I would just like to emphasize that WASM is bigger than just the web/Javascript/Node. One area where WASM is really gaining traction is in the blockchain space. Here are some notes I found from a WebAssembly meeting last April about WASM+blockchains: WebAssembly/meetings#206

The blockchain I'm particularly interested in is EOS, because it is a live chain that uses WASM for smart contracts. I have been working on bindings and a nice API for Rust developers:
https://github.com/sagan-software/rust-eos

The dream is to have my smart contracts, frontend, and backend all written in the same language where they can all share the same validation code. Currently this is only possible with Rust:

• Alternatives like AssemblyScript or Go are not fast or small enough to use for building smart contracts on a blockchain like EOS, where execution time and binary size are somewhat costly.
• No sane person would build a web frontend in C++.
• Blazor/C# might be a decent alternative but I don't know much about either of them.

For my target audience who are mostly not Rust developers (C++ or web developers) the biggest pain point is getting an optimized .wasm file generated. It would be great if wasm-pack could optionally act as a more general-purpose WASM optimizing tool that:

• Doesn't depend on wasm-bindgen
• Could automatically install wasm-opt
• Would enable LTO by default

Also it would be nice if:

• wasm-pack test/wasm-bindgen-test could be extensible to support non-web environments.
• wasm-bindgen code could be benchmarked in browsers (rustwasm/wasm-bindgen#828)

[mstallmo]

Big fan of everything on this roadmap! If we can execute on all these points we will be in a really strong place in the WASM community!

[alexcrichton]

I'm personally also a big fan of the proposed roadmap here. It feels both achievable and moving us a good distance further forward from where we are today. Thanks for taking the time to write this up @fitzgen!

---

@jgarvin to be clear this roadmap intentionally does not exclude all-rust web applications, but rather the opposite! The section mentions saying "yes and" to this focus, which I think encapsulates the roadmap's intention very well here. It's basically saying that everything you'd need to surgically replace some JS with Rust you'd also need when building a whole web app in Rust. You'll likely need some other pieces for a full app as well, but those pieces are sure to benefit surgical replacements as well! All in all, these use cases share a lot of similarities, and focusing on one vs the other is largely on some adjustments here and there.

I personally see the "small modules" use case as more difficult to tackle in the fullest due to the larger constraints on toolchain interop, language interop, etc. I like the idea of tackling the hardest problems first, and this'll get use a huge head start on tackling other problems head on the future, and of course doesn't prevent solving other problems in the meantime!

---

@gnzlbg ah a good point! I think we may want to brainstorm something to add to the "Toolchain and Workflow Polish" section because I agree that our testing story isn't quite as buttery smooth as it is for normal Rust code right now, but that doesn't mean we can't make it better!

---

@jamii we don't currently track Rust wasm-specific toolchain performance in a way such as perf.r-l.o, but we're always interested in keeping an eye on it! If you've got cases that are too slow we'd love to know about them to see where we can dig in and improve.

---

@liamcurry it's true that wasm is more than just JS! Sort of like the point above with all-rust web applications I feel that pushing our story in other areas with JS will naturally fall out in improvements for other non-JS usages of wasm. I don't think wasm-bindgen/wasm-pack will be the right tooling for non-JS use-cases, but they're good examples to draw from!

[fitzgen]

@gnzlbg,

Sad not to see running unit tests reliably in the Roadmap. wasm-bindgen-test should always work.

Can you expand on this a little bit? Have you run into bugs that we need to have issues on file for?