How WebAssembly Works

Posted 2021-04-25 ASPNETCore

Blazor is an exciting new web framework from the ASP.NET team that uses Razor, WebAssembly, and Mono to enable the use of .NET on the client. There’s been a lot of excitement about the possibilities this presents, but there’s also been just as much confusion about how these various parts fit together. In this post I’ll attempt to clarify things and show you exactly what each of these technologies do and how they work together to enable .NET in your browser.

How JavaScript Works

Before we start examining some of the more recent pieces of this puzzle, it’ll help to take a step back and look at what happens inside your browser when it loads and evaluates javascript code:

Inside every browser is a JavaScript runtime (or engine) that's responsible for turning your JavaScript into something that can be evaluated. It's often referred to as a virtual machine since it presents a well-defined boundary in which the code is evaluated and isolates that evaluation to a specific sandboxed environment. This diagram is a gross oversimplification of modern JavaScript engines, but they all generally consist of three stages:

• Parser - Performs lexical analysis on the JavaScript code and converts it into tokens (small strings with specific meaning). The tokens are then reassembled into a syntax tree that gets used in the next step.

• Compiler - Transforms the syntax tree into bytecode, which is a low-level representation of the code that the interpreter can quickly understand and evaluate.

• JIT - A just-in-time interpreter that takes the bytecode and evaluates it on the fly at runtime, thus executing your code.

I'm sure I've misrepresented or totally missed certain subtleties of this process, so if you see anything glaringly wrong please sound off in the comments. The important point here is that the JavaScript engine that exists in every browser takes your JavaScript code, figures out what it means, and then evaluates it inside the browser.

How WebAssembly Works

WebAssembly is described by the official site as:

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

That’s not particularly helpful since it’s intentionally abstract to allow for future implementation changes. What’s important for our purposes is to understand how WebAssembly interacts with the existing JavaScript support that’s already in your browser. Here’s that chart again with the addition of WebAssembly bits:

Blazor

All of this sets up the exciting work going on in Blazor itself. Blazor is the name of a project that includes both a runtime component and various tooling. The tooling helps produce the assemblies that the runtime bits know how to work with. What gets delivered to your browser looks like this:

There's a lot going on here so let's examine each part:

• Blazor Page - The html file that Blazor produces is really simple. It basically just includes CSS files and headers as well as a couple JavaScript files to help bootstrap the WebAssembly support (WebAssembly modules currently have to be loaded by JavaScript).

• blazor.js/mono.js - These JavaScript files are responsible for loading the Mono WebAssembly module and then giving it your Blazor application assembly. They also contain support for features like JavaScript interop.

• mono.wasm - This is the actual Mono WebAssembly .NET runtime that mono.js loads into the browser. It is basically Mono compiled to WebAssembly.

• mscorlib.dll, etc. - The core .NET assemblies. These need to be loaded just like any other .NET runtime otherwise you'll be missing key parts of the .NET System namespace(s).

• myapp.dll - Your Blazor application which was processed by the Razor engine and then compiled by the Blazor tooling. Today the tooling exists as MSBuild tasks that get added to your project by the Blazor NuGet package.

The end result is Razor and C# in your browser! 

一个人可以走得很快，一群人可以走得很远。