Improving Webassembly and Its Tooling -- Q&A with Wasmtime’s Nick Fitzgerald

Improving Webassembly and Its Tooling -- Q&A with Wasmtime’s Nick Fitzgerald

WebAssembly, now a web standard, aims to grow beyond the browser. Wasm runtimes are implementing proposals to achieve this vision. Fitzgerald tells us about his recent work on WebAssembly tooling and his implementation of reference types in the Wasmtime WebAssembly runtime -- a prelude to interface types and easy interoperation between Wasm and a host language.

Key Takeaways

  • WebAssembly’s first major version focused on the browser. WebAssembly is now expanding its focus beyond just the browser with a series of features designed to enable its vision of a portable binary format on many platforms, bringing great benefits in tooling and language-agnosticity.
  • A large number of non-browser runtimes have appeared with different areas of focus (performance, size, and more).
  • The Wasmtime runtime recently implemented the reference types proposal, allowing Wasm modules to properly interact with external host objects. This means better integration between a Wasm module and the outside world (DOM APIs when loaded inside a Webpage, or with a database API when instantiated on a server).
  • Thanks to the wasm-smith test case generator, hard-to-find bugs in the wasmparser Rust crate have been fixed
  • Next candidate features are type importsinterface typesmodule linking, and more.

WebAssembly recently became a World Wide Web Consortium recommendation and the fourth language to run natively in browsers, after HTML, CSS, and JavaScript. While WebAssembly’s first major version focused on the browser, WebAssembly is now focusing to non-browser environments to fulfill a variety of computational tasks, where sandboxing, portability or performance are essential. In this context, non-browser-based WebAssembly runtimes are being developed in miscellaneous languages, (Wasmtime and wasmer in Rust, GraalWasm in Java, Lucet in Rust, py-wasm in Python, swam in Scala, and more), with different areas of focus (e.g., performance for wasm3, blockchain applications for eos-vm, small footprint for wasm-micro-runtime). One challenge for these runtimes is to implement and experiment with the new batch of WebAssembly proposals that strive to fulfill WebAssembly’s vision outside the browser.

Although Wasmtime is implemented in Rust, the developers maintain APIs for embedding it within various other languages:

As Wasmtime recently implemented the reference types proposals, InfoQ interviewed Nick Fitzgerald, who implemented the feature, on his work involving WebAssembly and the next steps for WebAssembly and Wasmtime.

InfoQ: Can you tell us more about you?

Nick Fitzgerald: I work on the Wasmtime WebAssembly runtime, the Cranelift code generator, and various parts of the Rust and WebAssembly ecosystems.

Outside of work, I enjoy riding bikes (both for getting places and for doing fun tricks on my BMX), listening to hip-hop (I’ve had “CLONES” by Tierra Whack on repeat recently), and reading books (I just finished The Fifth Season by N.K. Jemisin and it was stunning!). I occasionally make algorithmic art and draw it with a pen plotter. Pen plotters are a precursor to modern printers—pretty much obsolete and only used by artists these days—that hold a pen in a little robot arm and draw vector graphics. I recently adopted a kitty cat from the local humane society; his name is Goomba. My pronouns are he/him.

InfoQ: How did you get involved with WebAssembly?

Fitzgerald: I stumbled into WebAssembly, but looking back this wasn't really an accident: I was in the best position to stumble into it I could have been.

I used to work on the Firefox Developer Tools team at Mozilla, where I wrote and maintained our source map support. Source maps are a simple debugging information format for JavaScript. Minifiers and compile-to-JavaScript languages like TypeScript or Elm will emit them alongside their generated JavaScript code. The source maps allow debuggers and similar tools to translate locations in the generated code into locations in the sources that the developer originally authored. Source maps contain similar information as DWARF’s .debug_line section. With a source map, for example, the developer tools can show you “line 42, column 8 in my-module.js” rather than “line 1, column 643243982346519205631 in file minified-bundle.js.”

So here is the first connection: I was already working on tooling that helped people write code for the Web in a language that wasn’t JavaScript, should they choose to do so. WebAssembly also helps enable that, but now without compiling to JavaScript as an intermediate step. But all of this started before asm.js (a WebAssembly predecessor) was even a thing.

Anyways, source maps can contain a lot of information, so the format goes to great lengths to compact that information in as dense a representation as possible. Even so, source maps can get big, and decoding them can get quite expensive. When loading a Web page, the developer tools have to parse a source map before they let the page execute JavaScript, so that they can do things like set user-requested breakpoints in regions of top-level code that are only executed at start-up. This has to block: if it didn’t, and was asynchronous, then we have a race condition between whether we will finish parsing the source map in time to set the breakpoint, or whether that start up code will already finish executing before we get a chance to set our breakpoint. Because parsing source maps is on the critical path of reloading Web pages when the developer tools open, we care quite a bit about its performance.

Our library for parsing source maps was written in JavaScript. Over the years, we applied many optimizations and performance improvements to the library. We were bending over backward to avoid allocations and restructuring object layouts and function bodies so that Firefox’s JavaScript JIT compiler could better understand and optimize them. But we noticed that the more we optimized this code, the less idiomatic and less maintainable it became.

Fast forward a few years and WebAssembly has just started shipping on all major browsers and the Rust compiler has the brand-new wasm32-unknown-unknown compile target for compiling Rust programs into WebAssembly. I’m no longer on the Firefox Developer Tools team, but I had some free time over the 2017 winter holidays, and I wanted to try compiling some Rust to WebAssembly. Tom Tromey and I started brainstorming and bouncing ideas around, and we finally came up with the idea of replacing the core of the source map library with Rust compiled to WebAssembly and an architecture for doing that effectively. At the time, no one had been integrating Rust and Wasm into JavaScript libraries yet, and most uses of Wasm, in general, were monolithic C/C++ programs with tiny bits of JavaScript glue at the edges. People weren’t surgically replacing compute-bound kernels of JS code with small bits of Wasm like we were attempting, so we didn’t have a lot of direct examples to lean on.

When we finished rewriting the core of the source map library, we found that not only was the new code much faster, but it was still idiomatic. Rust didn’t force us to choose between runtime performance and clearly expressing our intent. For example, avoiding allocations in Rust (something that was a huge pain in the JavaScript codebase) is not only easy but natural thanks to Rust’s ownership and borrowing systems. To learn more about this project, check out my article Oxidizing Source Maps with Rust and Wasm on the Mozilla Hacks blog.

After the source map project, I was given the opportunity to work on Rust and WebAssembly full time at Mozilla. I led the Rust project’s WebAssembly working group, where we fleshed out the Rust and WebAssembly ecosystem and tooling. These days I’m focusing on the Wasmtime WebAssembly runtime for running Wasm outside the Web and the Cranelift code generator that Wasmtime uses under the covers.

emerging technologies webassembly devops architecture & design development article

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Hire Dedicated DevOps Developers

Hire our Dedicated DevOps Developers who have in-depth skills and expertise to develop an interactive and secure web application. Get custom DevOps solutions for your project.

Hire DevOps Developer

Looking to hire top DevOps developers at affordable prices? **[Hire DevOps Developer](https://hourlydeveloper.io/hire-dedicated-devops-developer/ "Hire DevOps Developer")** from **[HourlyDeveloper.io](https://hourlydeveloper.io/...

How long does it take to develop/build an app?

This article covers A-Z about the mobile and web app development process and answers your question on how long does it take to develop/build an app.

Glossary: Design Systems Defined for Developers and Designers

Design systems are interdisciplinary by nature. They are built and consumed by designers and developers, therefore it is important for common terminologies to exist to support the communication between these two disciplines and other related actors.

Developer Career Path: To Become a Team Lead or Stay a Developer?

For a developer, becoming a team leader can be a trap or open up opportunities for creating software. Two years ago, when I was a developer, ... by Oleg Sklyarov, Fullstack Developer at Skyeng company