I'm Derek Schuff and I work on WebAssembly and together with my co-chair Luke Wagner we're going to give you an update of where we are with WebAssembly and where we're going.

But first, what is WebAssembly?

The one phrase version is that it's a binary instruction format for a virtual machine.

This especially includes but isn't limited to the virtual machine that is already in your web browser.

But it's a binary format because it's meant to be produced by compilers, so that you can write in any programming language that you want.

This makes it complimentary to JavaScript.

JavaScript is an instruction format for a virtual machine, but it's also a programming language with its own style and conventions.

So even aside from the benefit of using your favorite language, the advantage of having another lower level way to express computation also allows adding capabilities to the web without trying to force every programming language concept ever invented into a single language.

But why do we want to do this in the first place?

WebAssembly is really all about the web's role as an application platform.

We want to bring more and better applications to the web.

And there are three use cases in particular where this is especially helpful.

The first is cross-platform apps.

There are a lot of platforms that are relevant today, both desktop and mobile.

And developers are already targeting these with cross-platform applications, many of which are built on cross-platform languages and frameworks.

So bringing those languages and libraries to the web allows those developers to target the web easily as well.

In addition, there's already a lot of code existing in the world in other languages and for other platforms.

And these can be brought to the web without having to be rewritten, which is a big advantage.

The third is performance, exposing CPU capabilities at a lower level with more predictable performance enables some kinds of apps that otherwise just wouldn't be possible or wouldn't work as well.

Things like image and video processing, games, data analysis, and some others.

And finally, we can make the web more accessible to more developers regardless of what languages they already use.

So where have we been?

In 2015 we formed the WebAssembly Community Group and we established some processes for how Wasm would be developed and specified.

These are informed by our experience in W3C and JavaScript standards body.

A part of that is the incubation process, the way proposals go through phases in the Community Group before graduating to the Working Group and the final spec.

In 2017 we charted the Working Group itself and we came to an agreement on the first minimum viable version of the spec, and we worked on shaping that in browsers.

Then we worked on the W3C Working Drafts and this eventually led to a REC in 2019.

During that time, along with shepherding the spec through the W3C process, we were quite busy and we had a lot of growth, both in terms of the things that we wanted to add to WebAssembly itself and in terms of the people and groups and stakeholders that were involved.

So we added a bunch of feature proposals to the standard, including small things like sign extension instructions, and really big things like SIMD, which is a really important performance feature.

We also expanded our working processes to include subgroups.

These are focused on a particular topic and they track more complex and longer term efforts involving multiple proposals.

And very soon we'll start a new working draft to include all these proposals that we've added.

And we're also considering going to an Evergreen standard.

So where are we going in the future?

We have a bunch of active design work going on, primarily in the form of in-progress feature proposals and subgroups, and these broadly breakdown into three different categories.

The first category is making better use of the CPU capabilities that are in everyone's hardware today, even low-end hardware.

This include things like threads with shared memory, use of 64 bit addresses to allow addressing of more than two or four gigabytes, and more CPU instructions, primarily more SIMD.

Secondly, we're wanting to enable efficient support for more language features.

So this includes some basic things like exception handling, also stack switching, which is a primitive that can be used to build several different kinds of capabilities on top of, and probably the biggest one is garbage collection.

This enables compiled languages to efficiently use the garbage collector that's already built into the platform and it's used by JavaScript.

The third category is improving integration between code compiled to Wasm and its surrounding web environment.

So this is, for example, exposing compiled Wasm modules as ECMAScript modules, type reflection to expose Wasm types into JavaScript and Web Content Security Policy, which integrates with existing mechanisms for securing web apps.

It turns out that despite its name, WebAssembly isn't just useful on the web.

So, now I'll turn it over to Luke who will talk about what's happening outside of the browser.

Thanks Derek.

When we started Wasm our primary use cases all focused on the browser.

We weren't sure if anyone would want to use Wasm outside the browser.

But based on what we had seen with JavaScript and Node.js, it seemed like a possibility.

So we made the early decision to make sure that Wasm didn't have any hard dependencies on running only inside a browser or JavaScript engine.

Since the initial release of Wasm in 2017 we've been pleasantly surprised to see that folks are in fact, adopting Wasm outside the browser to provide unique value they couldn't get otherwise.

Some examples we've seen in production include Fastly using Wasm for low latency compute at the edge.

Envoy using Wasm for low latency, proxy, and router, filters and plugins.

And Shopify using Wasm for low latency, high scalability apps running on their platform.

And there are a number of other exciting new embeddings in progress.

So why are they using Wasm?

Well, there's a lot of reasons, but to pull out two themes that I've seen: First, people are using Wasm to move code closer to the data or to their clients.

And second, people are using Wasm to avoid baking in a single scripting or domain specific language into their platforms.

So that's all exciting, but one thing that has become increasingly clear is the need for new supplementary open Wasm standards.

You see, with the WebAssembly 1.0 core specification we were able to get away with specifying the absolute minimal thing; just the raw ability to compute and import things from the outside world, and that's it.

And we could get away with this because we implicitly relied on the outside world being a browser with all the rich functionality of the web platform.

But outside the browser we don't have the web platform and so these novel embeddings of Wasm have had to invent their own bespoke APIs and SDKs.

With new standards these hosts would have the option to share tool chains, run times, documentation, concepts, design work, and reasonable modules of code.

The first standards effort we started around two years ago is called WASI, which is short for the Web Assembly System Interface.

This is not a single monolithic standard, but rather an umbrella effort to standardize many independent standard interfaces such that any particular host can choose to implement just the interfaces that make sense on that host.

Under the WASI umbrella there are some common goals though.

First, there's an emphasis on security; in particular, maintaining Core Web Assembly sandbox model and supporting the Principle Of Least Authority.

And second, there was a goal of making all the WASI interfaces virtualizable which means among other things, that WASI interfaces can always be implemented not just by the host, but by other Wasm modules too.

And this unlocks a whole lot of valuable flexibility for developers like the ability to polyfill missing functionality.

The original WASI proposal included proposed interfaces for clocks, randomness, and file systems.

Since then, as more folks have gotten involved and we've looked at more use cases, we've started working on a number of other interfaces, including IO, which defines abstract stream and array I/O operations that can be decoupled from the file system, and thus usable on hosts which don't necessarily want to expose a file system to the guest Wasm code.

HTTP, which factors out a common API from multiple existing Wasm embeddings, including Fastly and Envoy.

Wasi-nn, which is an interface focused on machine learning.

Wasi-parallel, just an interface focused on performing data-parallel compute within a single node.

And wasi-data, which is an interface focused on distributed data processing across a whole network of nodes.

The next major standards effort underway has recently been re-scoped and renamed to be called the Component Model.

The Component Model starts with the question of 'what takes the place of the operating system process model?' In particular, how do Wasm modules communicate, especially when they are produced by different tool chains from different languages and running on a diverse set of systems?

How do I as a developer compose multiple Wasm modules into my program or into a new compound as a module that others can reuse?

This is easy and normal to do within a single language's module ecosystem, but much harder to answer when we're talking about modules from different languages.

And lastly, how can I implement a WASI interface with another Wasm module?

Previously, I mentioned that a goal of WASI is to ensure WASI interfaces are virtualizable, but how does a web developer concretely go about doing that?

In a browser, these questions are answered by well-defined concepts like Window, Worker, Module, and combined with the JavaScript API for WebAssembly specification.

But outside the browser, what should we do?

Should we just standardize POSIX and Wasm?

We could, but POSIX doesn't necessarily align with the new ways people are using Wasm.

Where there isn't even necessarily a file system, we don't necessarily want to conflate Wasm instances with processes.

So instead, we're looking at defining something lighter weight with more of an ES module feel that maintains the same lightweight footprint as current Core WebAssembly.

And we're calling it the Component Model.

The Component Model is being developed as a new layered spec that sits above the WebAssembly Core specification and sits under the WASI standards, providing WASI with the foundation it was missing before; like how separate modules are composed and how interfaces can be virtualized.

The Component Model also aims to give tool chains a clear binary target to compile to, like a traditional OS ABI.

The Component Model specification effort contains two proposals that have been in active development for the last couple of years.

The first is Module Linking, which allows Wasm to link Wasm modules from within Wasm instead of relying on host-specific functionality.

And the second is Interface Types, which allows modules to define their public interfaces in terms of high-level types, including value types, like strings, lists, records and variants.

Handle Types, which allow passing references to resources that you can't or don't want to copy like sockets, connections, widgets, or blobs.

And async functions and streams, which allow cross-language concurrency.

So that's it for WebAssembly standardization efforts outside the browser.

If you're interested in anything Derek and I talked about we have some helpful links here for you.

There's a great developer guide with a bunch of material for a bunch of different languages and tool chains.

You can browse the specifications online.

You can see the active proposals the CG is working on, including what phase of the process they're in.

If you want to get involved, the link page points you to the W3C Community Group that you need to join first, as well as our GitHub org, Discord channel and the code of conduct.

And lastly, the meetings repo contains the past meeting minutes and upcoming meeting agendas with dates and instructions for joining.

Thank you.