Nerding Out About: WebAssembly (WASM)

Added: 2026-06-02

[00:00:00]Welcome back to nerding out about software. Today's topic is WebAssembly.

[00:00:05]We're explaining what WebAssembly actually is, what the most common use cases for it are, the limitations of it to know what it's not necessarily well suited for, and then I'll show you a few examples ranging from simply calling a WebAssembly function from your JavaScript to a whole library compiled into WebAssembly and pulled in from NPM to a desktop application that can be run both standalone as a native binary and inside your browser through WebAssembly.

[00:00:34]WebAssembly is a separate compilation target compared to your usual native binaries for x86, ARM, RISC, and so on.

[00:00:42]We start the same way from feeding our source code to the compiler, passing through the lexer, the parser, with the AST, and producing an LLVM intermediate representation.

[00:00:52]But, that's where we diverge.

[00:00:54]In your usual native executable route, you create machine code in your object files that gets turned to a native executable that can be [music] immediately understood by your CPU.

[00:01:07]In WebAssembly, we first create the object file with WASM objects that get packed into a WebAssembly module. Now, this module can be picked up by the host runtime of your browser and just-in-time compile to something that your CPU can understand.

[00:01:24]So, instead of compiling for running something natively on the machine, we compile it so a browser can make it run natively on the CPU. This has some absolutely great use cases. Namely, you can pick up any native library or even a whole program and run it client-side without re-implementing it in JavaScript. So, instead of having to parse your entire code base, you can compile it into a WASM module and have that code usable within your web page. It also has some performance benefits in very particular cases, and that's that's an important point to stress. It's very useful for memory bound byte work, so processing images and audio. And since you can run your code from a language that doesn't have a garbage collector, it doesn't get impacted by a garbage collector.

[00:02:12]So, anything that needs real-time response such as video games, audio processing, if you wanted to make a web only digital audio workstation, you would want to use WebAssembly for that. And also, it can technically do SIMD, so single instruction multiple data, which is quite difficult and a topic we could cover in another video in the future.

[00:02:36]But that's something that JavaScript cannot natively do by itself and can have significant performance benefits.

[00:02:42]That said, for your usual scalar maths, uh your just-in-time compiled JavaScript is actually really well optimized in the V8 engine. So, it can be equally fast or sometimes even faster because the first time you load a WebAssembly module, there will be a slight cold start to it. Now, what WebAssembly cannot do is it cannot directly modify the DOM. So, your UI remains bottlenecked by your JavaScript. If you thought I could simply replace React, never use it again, just use WebAssembly, it's not as simple as it may seem initially.

[00:03:19]You are still bound by the same DOM, by the same virtual DOM ideas.

[00:03:24]If you wanted to fully replace React, you would want something more than just, "Oh, I use WebAssembly next to my JavaScript." You want to have a full framework such as Dioxus in Rust, or you would want to have your entire web application have all of the rendering done in something like Rail or Macroquad and compile into WebAssembly.

[00:03:45]So, let's look at a very simple example of WebAssembly. In this case, we will write a few functions in Zig and we will call them from a compiled web assembly module in JavaScript in our web page.

[00:03:57]We're using Zig because it's one of the in my experience easier languages to do web assembly in alongside Rust. It's one of the better ones where all the tooling is quite mature and works quite well.

[00:04:09]So in this case, we've got a very very simple function of addition.

[00:04:14]Scalar in, scalar out, which is sort of the simple case. We get some data, we return some data. But what web assembly also allows you to do is access the same linear memory as the JavaScript. So the JavaScript for our sum function will simply write bytes into the linear memory shared with the module and we will sum over them. For that we just write a simple sum function which just takes a pointer to the memory and iterates over the things in there and returns the total.

[00:04:50]But for that we also need to create this little scratch which is a pointer to that linear memory to write into.

[00:04:58]Wiring this up in our main.js is not particularly complicated. We will simply use your browser's built-in web assembly API, so we don't need to do anything particularly complicated. We just have our instance of web assembly instantiate streaming taking our simple file and then we export from that instance all the functions that we marked with export function in our Zig code and also the memory which is the module's linear memory that we will be accessing. The rest of it is very simple JavaScript pointing things at it. The interesting bit happens in the sum function where we get to the point where our view has this Uint8Array with the memory buffer. So the memory.buffer is actually that shared piece of linear memory. We simply ask the Wasm module where its buffer lives, write our bytes there, and then call the sum function on it. Putting that into a very simple bit of HTML and CSS, we get a basic website where we can put in numbers and get results.

[00:06:06]We simply add two numbers, get the result, and for shared linear memory, we can put a list in there, click the sum, we get our outputs. So, this is ridiculously simple and it's as simple as you can imagine for doing WebAssembly, but of course, those are not the interesting implementations we want to look at. That said, it can already scale quite powerfully because whatever function you can come up with, you can compile, you can run. So, anything that is very complicated for working with memory-bound problems, you can just write a function in WebAssembly and call it from JavaScript rather than implementing it inside of JavaScript.

[00:06:45]Now, the interesting way of doing WebAssembly is where you may have encountered before, just not realized it, which is compiling whole libraries. In this case, we'll look at FFmpeg, which is one of the best C libraries ever made, into WebAssembly and using them as any JavaScript library you would ever use.

[00:07:04]>> [music] >> So, in this case, we pull FFmpeg core and utils from dependencies from npm.

[00:07:11]Means we don't actually need to do any compilation in WebAssembly ourselves, and we will use it like any other module. So, you may not even realize that what you're pulling in as your dependency is actually a compiled C program in WebAssembly rather than using a JavaScript dependency for it. In our main.js, we don't do anything particularly special. What we need to do is import it, set some basic event listeners for our buttons and parts of our page, but what is interesting is what happens on click when we actually get to that point. In this case, on our click event, what will happen is we will take what we've got there and we will do FFmpeg execute. And what you'll see is you have your {dash}i input name {dash}c colon v libx264 output mp4. This is exactly as you would use FFmpeg from your command line, but instead we are just calling that function inside our JavaScript, calling into that WebAssembly module to do some video processing. In this case, it's a simple conversion to mp4 using the H.264 codec.

[00:08:14]Looking at the actual, again, very rudimentary website with barely any HTML and CSS, we have our simple converter where we can upload a file, in this case, a random video of Terry Davis, and click convert to start converting it. And if we now inspect our console, we will see that the output of the FFmpeg command is printing as it's going along because we said that hidden to false, just like you would see running it inside of your terminal. Now, the use case I find quite fun for WebAssembly is taking a desktop application with all of its own graphics rendering and porting it into the web using WebAssembly without changing any of the application code. For the purpose of this example, we'll be using macroquad in Rust.

[00:09:06]Macroquad is essentially a Rust native alternative to raylib, you could say, which is good for us because it means we will simply do a single compilation step of compilation into the target of WebAssembly without having to play with Emscripten like you have to do for C libraries like raylib. In this case, our application is moderately simple. All we'll have to do is a clear black background with nothing happening until you click. On click, we will be spawning little balls that will be gravitating around our cursor and move together with it. If we simply call cargo run, we get a simple native application where we see we have object spawning, we have FPS numbers, and everything works.

[00:09:55]It's a very, very simple application.

[00:09:57]You can write this in minutes.

[00:10:00]But, what's interesting is putting that to web assembly now. For our build, all we have to do is call cargo build with the target set to web assembly 32 unknown unknown. We'll do a simple release build, and then copy the output module closer to the actual code. In our HTML, all we have to do is have a simple canvas that we will put our application in, and that's pretty much it, except for this little JavaScript bundle.

[00:10:28]This mq.js bundle is a macroquad miniquad JavaScript bootstrap that lets us run our application without writing any of the linking between JavaScript and web assembly ourselves.

[00:10:41]And the good news is it's entirely generic. So, we don't have to generate it for a specific project. We just grab that one file from macroquad crate itself, and we're done. All we're using in our HTML is this little bootstrap JavaScript bundle and our web assembly file. When we actually serve our HTML, we get the same application just inside our browser, which is quite remarkable. We don't have to change anything about our code. All we do is we compile for a different target, and then have a little bit of JavaScript pointing at it to let the browser know what it should be doing with it. You don't have to do anything different. It feels like compiling for arm versus x86.

[00:11:28]You're just simply compiling for, instead of a new type of CPU, you just compile it for a browser, and that's about it. So, WebAssembly has definitely interesting uses.

[00:11:39]It can be great for porting entire programs you would normally rewrite entirely from scratch, but it cannot replace every single thing unless you rewrote the entire virtual DOM approach in something like dioxins and rust. So, let me know what you think. Do you think you'll start using WebAssembly in some of your projects, or are there benefits not necessarily useful for your particular use case?