When I started to explore the world of WebAssembly, I thought that the goal of the project was to simply provide a way to run native code on a browser. In 2017 a first version of WebAssembly was shipped. It allowed native code to run in the broswer indeed, by compiling it to an agnostic binary format.

It is only after listening to Lin Clark speaking at JS Heroes conference in Cluj earlier this year that I realized that what was released in 2017 was just an MVP (a Minimum Viable Product) and that there’s so much more to come in the near future.

She’s amazing in explaining how WebAssembly (and the web in general) works, I highly reccomend you to read as many as her articles as you can:

• Intro to WebAssembly
• Creating WASM modules
• Firefox’s WebAssembly compilers
• Post MVP features

Let’s bring these amazing updates to Paris! 🥖

In spring 2019 I proposed an introductory talk about WebAssembly at the JS-focused meetup ParisJS. The folks there put a very democratic system to decide which talks will make it to the next meetup: you have to open an issue in a GitHub repository and wirte a brief description of what your talk will be about. The most voted/commented talks get scheduled for the next edition of the meetup.

We quickly realized that all the WebAssembly-related proposals were getting a lot of traction, and therefore decided to organize a special edition of ParisJS, focused on Webassembly.

The video of the talk I gave at the meetup is available on both youtube and dailymotion(full video of the meetup here).

If you’re interested in checking out the slides, here you go.

What is WebAssembly (at least the MVP)

By quoting the official WebAssembly documentation:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.

It’s a way to run native code on the browser by compiling it to an agnostic binary target. The agnostic part means that WebAssembly makes no assumptions on what is the initial language the native code is written in.

Any language can potentially be compile to WebAssembly.

Wasm was created with 3 main aspects in mind:

• It had to be fast, therefore it needed to be a very compact compilation target. Fast in 2 ways:

  1. In terms of execution
  2. In terms of loading
• It had to keep working in the sandboxed environment which is a web browser. This feature of browsers provides an important level of security which allows the users to run 3rd party code they don’t know on their machines without having to worry too much.
• For Wasm this applies particularly when talking about memory management. The kind of apps that we want to compile to WASM need to directly manage their memory and at the same time we didn’t want to lose the security features of the browser environment. Therefore WebAssembly uses a specific linear memory when executing, which provides it flexibility and security at the same time.

That was pretty much it for the MVP. This set of amazing features already allowed many developers to start to port very complex apps to the browser and develop performant libraries which wouldn’t have been possible before.

But as I said before, there’s much more on the roadmap! The current set of features is enough for some kind of applications but it still isn’t for many others.

The WebAssembly working group

Before diving deeper in the next WebAssembly features, I’d like to quickly recap how the group of people behind the standard validate a new spec.

The design of WASM is available on GitHub and so are the new features which are being standardized right now.

As you can see there are many things the team is working on right now and some of them are already in the testing / shipping phase.

And if you’re wondering what the Wasm working group is, here we go:

The mission of the WebAssembly Working Group is to standardize a size- and load-time-efficient format and execution environment, allowing compilation to the web with consistent behavior across a variety of implementations.

Here’s the process they follow when defining a new feature.

A feature has to pass many stages before being officially standardized:

1. Theres a first stage called Pre-proposal which can be translated to “A Community Group member has an idea” and everyone can have one. The first step is simply to open an issue on GitHub and that’s something everyone can do.
2. After that we pass to feature proposal step which requires the creation of a repo where the specs for the new feature will be designed.
3. As soon as a design spec is available we enter the “Proposed spec text available” step
4. After a prototype and a test suite are developed and we can move to the Implementation phase where as you can imagine browsers and other embedder can start implementing and testing the feature
5. As soon as some implementations are available the working group will start the standardization process on the feature
6. And when consensus will be reached the feature will become part of the WASM standard.

The most important thing I want to underline is that the process is opened to everybody, a new feature can be proposed by any member of the community!

---