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 (Is a wasm-bindgen-bench crate possible today? 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?

[gnzlbg]

@fitzgen

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

The current system works, but if I want to run the tests of a library using both libtest and wasm-bindgen-test I need to write:

#[cfg_attr(not(target_arch = "wasm32"), test)]
#[cfg_attr(target_arch = "wasm32", wasm_bindgen_test)]
fn my_test() { ... }

instead of just

#[test]`
fn my_test() { ... }

We probably want to make the whole wasm-bindgen-test thing a custom-test-framework, so that people only need to add something like:

#![cfg_attr(target_arch = "wasm32", custom_test_framework(wasm_bindgen_test::runner))]

to the crate root.

Ideally, this shouldn't be required either. That is, cargo test --target=wasm32-unknown-unknown or similar should just do the right thing and choose a default test framework that's actually able to run wasm32-unknown-unknown tests.

[fitzgen]

One thing that kept coming up in hallway discussions during the rust all hands in Berlin was keeping an eye on code size. The ability to emit wasm with small code size is a core advantage of Rust in this space, but at the same time it is something that is easy to let slip if you aren't keeping an eye on it. I think it would be good to strengthen our culture of code size as part of the larger growing of our ecosystem that this roadmap already talks a bunch about. We have Twiggy, but we can do more to promote small code size in the ecosystem, particularly for library crates used for wasm.

Concretely, I'd like to propose we build perf.rust-lang.org-style infrastructure where we build a selection of wasm projects and record their code size every day. The projects would be selected to cover various popular wasm crates and exercise a wide breadth of our toolchain. We would have a dashboard of graphs showing code size over time, and it would let you drill down into each test case further. If we end up with multiple implementations of libraries for X, we could potentially have code size leader boards comparing them head to head. It would also be good to keep an eye on the code size of std things with this infrastructure as well.

I think this dovetails nicely with both the modular toolkit / ecosystem items already in the draft roadmap right now, as well as the kinds of holding-ourselves-accountable monitoring that @jamii is calling for.

[fitzgen]

Okay! I added a new item on testing, profiling, and monitoring infrastructure: https://github.com/fitzgen/rfcs-1/blob/2019-roadmap/text/007-2019-roadmap.md#monitoring-profiling-and-testing-infrastructure

With that, I'd like to nominate that we merge this RFC!

---

Disposition: merge

@rustwasm/core members to sign off:

• @alexcrichton
• @ashleygwilliams
• @fitzgen

[fitzgen]

Gentle nudge @ashleygwilliams:

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.

[TitanThinktank]

@liamcurry

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:

many people are giving lip service about this inevitable future to avoid embarrassment, but deep down they are scared that Rust might replace JS and they will loose their demand, so these obsolete people keep pushing NodeJs and keep blocking and banning guys like us when we speak up , but they cant stop progress since this is not 1984.

[Pauan]

@TitanThinktank Just FYI, you weren't blocked because you dislike NodeJS, you were blocked because of your rude remarks, off-topic posts, and refusal to listen to anybody (including team members).

If you behaved that way in any other open source project, you would also get blocked.

Nobody is obligated to listen to you, especially if you refuse to have basic common courtesy. Just because this is the internet doesn't mean that you can do whatever you like.

Also FYI, I dislike NodeJS and npm as well, but you'll notice I have not been blocked. Perhaps ponder on what the differences are between us.

[alexcrichton]

@TitanThinktank I'm gonna minimize that last comment of yours, but if this continues we'll be forced to exclude you from the rest of this discussion. Please be sure to respect the Rust and WebAssembly Code of Conduct when discussing RFCs issues and such.

[alexcrichton]

@ashleygwilliams another ping since last week to check the FCP proposal

[alexcrichton]

@ashleygwilliams it's been about a month since @fitzgen proposed FCP now for this RFC which is pretty important to the working group, if you're unable to make some time to review this would you be ok if we go ahead and enter FCP and/or merge it?

[alexcrichton]

🔔 🔔 🔔

This RFC has entered its final comment period. In seven calendar days, assuming no substantial new arguments or ideas are raised, we will merge it.