My Firsthand Experience with Rust + WebAssembly

For those of you unfamiliar with the development world, rumor has it, there’s a new type of code that may be the future of web development called WebAssembly (Wasm). Wasm is a low-level assembly-like language and allows a developer to write in multiple languages (C/C++/Rust) on the web at near-native speeds. Wasm is designed to complement running alongside with JavaScript, so it is not meant to be a replacement. For the experience and examples in this post, I will be using C and Rust to be compiled down to Wasm and use JavaScript to run them. For those who do no know Rust, it is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

My initial attempt of learning Rust + WebAssembly (Wasm) was going to be about micro-benchmarking to see for myself if it is going to be the future of web development and have faster times than native JavaScript (JS). It was going to deal with processing simple math, complex math, image processing, and parsing.

Nope.

This was that experience…

I used the wasm32-unknown-unknown setup (already had Rust installed) and tried Minimal working example from hellorust. As a Rust and Wasm noob, I had no idea what I was doing but blindly following instructions. Taking the first few commands from the Minimal working example:

What does wasm32-unknown-unknown mean?

What does cdylib stand for?

What does wasm-gc do and why is there a big.wasm?

I found out that it meant {architecture}-{vendor}-{system} and it is rust-cross. Which helps cross compiling Rust programs for different machines.

cdylib stands for exporting a C interface from a Rust dynamic library, which can later be used to compile to Wasm for all browsers to interpret (rfcs).

The big.wasm extension is just a way to name the .wasm file that includes unneeded exports, imports, etc. The wasm-gc command takes care of cleaning up the extraneous code (wasm-gc).

After a few (maybe 2-3 hours) of just researching what tools I’m using, what they’re doing, and what’s going on, this is the result of that. My github code. To run it, just open the index.html file in a browser.

Wasm-pack is a tool that packages Rust code into an NPM package to then publish and use.

This article is what drew me to wasm-pack. When I learned about wasm-pack, I thought to myself, “Oh! It’ll make compiling the Rust code easier and all I have to do is publish the NPM package and use it.”

Haha…yeah, no.

I was following this tutorial on using wasm-pack to create/publish my first Rust NPM package. The instructions and steps were very clear and straightforward. I didn’t run into any problems…except one.

When running wasm-pack init --scope MYSCOPE command, the wasm file and JS wrapper file around the wasm file were not there.

After another few hours of tinkering around, debugging, testing it on Mac and Windows, looking for a Linux computer, and contemplating just buying a new computer, I decided to post an issue on the GitHub page.

My issue was resolved with the help from one of the contributors of wasm-pack. Yay! My first open-source contribution! (indirectly?…kind of? No? ok)

With my problem of getting the .wasm and js wrapper files not compiling solved, I was able to publish the NPM packages here. Sweet. Let’s move on the simple math benchmarking between Rust + Wasm and JS.

This graph represents the time differences between all of the different ways that the additional functionality was implemented. For some reason, the Inline Wasm was recorded to have a constant 0.0ms time for each execution. I believe it is a mistake but never got to the bottom of it. Therefore, more testing had to be done.

The conclusion I took away from this particular experiment was that there might be a lot of FFI (Foreign Function Interface) calls that I am referencing that may give more room for errors than I would like.

Source code here.

To try to avoid some room for error, I have decided to do one more simple, arithmetic micro-benchmarking. I am using WasmFiddle as my online editor so that both Wasm and JS code live in the same exact realm and should have some uniformity behind-the-scenes. This time around, I have implemented the modulus functionality and will be using C + Wasm and JS.

Now, THIS has more promising results. Based on the graph alone, Inline Wasm seems to have a clear advantage. Coming close to 2nd seems to be an on-off tradeoff between Wasm and Inline JS.

Source Code here.

From these results, I concluded that Wasm will be something worth diving deeper into and making more applications with Wasm to see all the benefits it has in store for us. Of course, without saying, I still need to do some more tests and experiments to validate when Wasm may be faster and when JS will be faster.

From the articles I read, Wasm will be the definitive choice when it comes to harsher compute-intensive web applications like image processing or gaming with cleaner graphics. Here are some examples.

My next steps will be doing a bit more micro-benchmarking for my own sake, like comparing how fast Rust + Wasm parses data compared to JS since I heard Rust handles parsing very well. After that, I will probably use it to create some web applications to put it to the test.

In conclusion, I don’t think it is intuitive when starting to use Wasm, especially with Rust since both of them are still under a lot of development. However, using them for a little bit, I can see how powerful and easy it will be to use them in the future.

WebAssembly is “30X” Faster than JavaScript

Speed Without Wizardy

Get Started with Rust, WebAssembly, and Webpack

Demos – Hello, Rust!

awesome-wasm