WebAssembly and React: A New Era of High-Performance Web Applications

Hi. Welcome. Thank you so much for tuning in today. I'm so excited to talk to you about WebAssembly. And, you know, we're online, I just, I can't see you, but I still want to get a raise of hands. Do you know WebAssembly? I see some hands up. Maybe, maybe I don't. Do you know me? Raise your hand. No, I'm just kidding.

Hi. My name is Ramon. My pronouns are he, him, co-founder of the Bad Web Site Club Free Learning Initiative and a big advocate for community and learning mutually and from a community focus. It's, just gives me life. Let's dive right in. You might have heard of WebAssembly, or I'm going to call it sometimes Wasm. Let's dive right into what it is, and who better than the official website to give us the definition. WebAssembly, abbreviated as Wasm, is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications. And this is kind of a collaborative creation, and I'm so excited about this in particular.

But when we think about WebAssembly, I want to make a couple things clear. First of all, WebAssembly is not a programming language, and I've found myself thinking this as well. I want to go and learn WebAssembly, but I can't learn it the same way as I would say React. It's not a front-end framework that we learn and apply. What WebAssembly is is a standard for low-level bytecode. It's a compilation target, and you might think, what is a compilation target? It's something that we use a lot of the time when computing. It is a standard that we take our code, say in Go or Rust or C++, we compile it or translate it to WebAssembly, which we can then run in the browser. And I want to show you a couple of examples of WebAssembly running in the browser, which are quite fun. You might have heard of archive.org or, you know, the Wayback Machine. They have a library of old software that you can run, for example, with DOSBox in WebAssembly, like old games. By the way, small note, if you're doing a talk like this, don't go and research this, because you're going to spend a lot of time playing these games as well.

Prince of Persia is still one of my favorites. But it's not just for games. It's also for high-end software. For example, Squoosh is a software that is an online software in the browser that lets you run low-level, really efficient image compression algorithms. Now, you might think, well, can't I do that in JavaScript? And of course you can. But what's incredible about this is that it makes it possible for doing these image compressions in a really efficient way in places where JavaScript might be an unideal language for image compression. So you can take your pre-existing algorithms in C or C++ and run them in the browser.

But it's not just algorithms, it's whole run times. You might have heard of StackBlitz. This is a project that lets you do coding in the browser, but it's running a Node.js runtime in WebAssembly. Not your JavaScript engine from the browser, a Node.js runtime. And this can be as big as an entire piece of software. Some folks have got LibreOffice, if you're familiar with it. It's an open source Microsoft Office kind of software running code for code in the browser. It is a 300 megabyte download, but it's still amazing to me that you can run this in your browser.

But OK, Ramon, you've been talking about all of this browser stuff. What about server-side WebAssembly? Surely WebAssembly can't just run anywhere. And you'd be right, except the folks who have been working on this standard have been doing some incredible things. WebAssembly with a system interface or WASI allows us to have these system interfaces so that we can run WebAssembly pretty much anywhere. Now, if you're familiar with it—oh, by the way, you've got to see this guide that I've linked here from Lynn Clark. She's done this illustrated guide to WebAssembly, and it is incredible. So the way a program works is that it needs to interface with a system's resources, which a lot of the times are protected by a kernel. So the kernel will do things like give you access to your file system and other resources of your computer. So what WASI allows us to do is to have these and have these access to these system calls. But to be clear, it's not an operating system. I'm going to let them explain it better than I can. From the Wasmtime project, it's an API provided by the Wasmtime project that provides access to several operating system-like features, including files, file systems, Berkeley sockets, clocks, random numbers. It is incredible. So what you can do in currently when running programs is you take your C code, you translate it, you or compile it to elf for Linux, portable executable for Windows or Mac o for Mac, which is all well and good, but when it comes to WebAssembly, now we can take our C code, create a Wasm or WebAssembly binary, which can then be run on any operating system with this very important part here, a WebAssembly runtime. I'm going to quickly run through a couple of examples of these, because of course I mentioned Wasmtime, which is one of the most prolific ones, but there's a whole bunch of them.

There's Wasm3, which is written in WebAssembly, which is just incredible. There's Was0, if you want to do more Go stuff. There's Wasm3, there's Wasmer, and okay, cool, can we run Wasm3 in the browser? Well, there's a polyfill for it. It is remarkable of what folks are doing. So yeah, you can take these and run them on your computers, but what about in the cloud? Folks even have Wasm runtimes, for example, WasmEdge here for running in the cloud. Or even in a container. I'm going to drop some links here if folks want to pick up my slides later, I'll link them at the end so you can read more about this.

But then the question becomes, why run WebAssembly on the server? And I'm going to link, I'm going to show, if y'all have been around the WebAssembly world, you've probably seen this tweet before. I still want to show it off because I love it. It's from Solomon Hikes, founder, one of the people behind Docker, saying, and I'll read it, if Wasm and WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope that WASI is up to the task. Now, bear in mind the date, that was 2019. We'll come back to that later.

So the thing about WebAssembly is that it's designed from the ground up with a capability based security layer. This makes it effectively a sandbox. So things like supply chain security vulnerabilities are mitigated with WebAssembly. Every system call you make is declared on startup. So if you don't have that system call available to you, you can't do it. It's also polyglot. Because it is a runtime, you can compile any programming language that compiles to WebAssembly and run it anywhere. These modules, because they're a near binary format, are small, typed, and provisionable most of the time. Getting a Python runtime is currently a challenge that's being worked on. But this makes it really scalable and pre-optimized. And because it's near native, you can run it on bare metal because why not? This has a huge impact on speed. Don't take it from me though. Here's a talk from Luke Wagner that I really recommend about the ephemeral nature of WebAssembly modules. That is, you can spin it up and then throw it away. Keeping state becomes much less of a concern, and it really brings a new meaning to the phrase, have you try turning it off and on again. You're not only running your WebAssembly on your computers, as I said, and I wanted to try and like expand this illustration, but it turns out I'm not a very good artist and I didn't want to ruin this incredible drawing from Lyn Clark, so I made my own attempt and I apologize. I'm not a very good artist, but I hope this carries the point across. You can take your C code, compile it to WASM, run it in a WebAssembly runtime in the cloud. And because your code attaches to the system resources at startup, again, with the help of WASI, this has huge implications for us when writing code, because now we can write code without, for example, worrying about server setup. It's a WASM runtime. You don't need to worry about so many questions when you're starting up, say, a container.

This has huge implications for startup and shutdown times, for scaling, and for common security vectors, like I said. Some more reading here. Again, I'll link the slides.

So then the question becomes, is WASM production ready? And it is a relatively new and still work in progress runtime, but it's already being used by folks you might already know. For example, in the Functions in the Service, or I just like to say FOSS, world, you'll see folks like FASLI. DNO is a WebAssembly runtime. You've got SecondState and CloudFlare providing ways for you to write code that runs in WebAssembly. But it's also great for edge computing and microservices. You got folks like WASM Cloud, Fermion, Vercel, and Cloud Native Computing Foundation providing these services to customers already. It also makes your software as a service extensible. So you can write plugins for Figma or Istio, or Shopify, again, in any programming language, in a sandbox that runs in WebAssembly.

Now I have to admit, I don't know much about blockchain, but I know folks like Parity are providing ways so that you can write, what do they call it? Oh, smart contracts in WebAssembly, which gives them that sandbox and ephemeral capability. But hey, folks like Acre let you run your WebAssembly modules in embedded context. There's a lot of ways it's already being used, and hey, any gamers in the crowd, Flight Simulator lets you run, lets you write plugins for it in WebAssembly. So there's a ton of ways this is already being used. More links to read up on.

And yes, I did say that this is a work in progress because there's a bunch of stuff coming to WebAssembly like a component model, making these modules a lot more interconnectable and smaller. Neural network capabilities built into WebAssembly. Garbage collection and multithreading. There's a whole bunch of stuff that I highly recommend keeping an eye out for. And you know how I mentioned Docker? Well, first, let me show you a tweet from the next day from Solomon. Remember, 2019. So will Wasm replace Docker? No. But imagine a future where Docker runs Linux containers, Windows containers, and Wasm containers side by side. Over time, Wasm might become the most popular container type. Docker will love them all equally and run it all. And here's the thing. Last year, Docker announced this. So now we have a beta for running Docker with WebAssembly modules. The way it looks is you've got your container D, where you can have your containers as you would normally, but you also, using the Wasm Edge runtime, have WebAssembly modules running in your containers.

So yeah, a lot of this is very new and work in progress. But as you can see, it's already being used, and the future looks extremely bright.

So cool. I've been going on about this for a while, you might be wondering, hold on, what a React conference? You're talking about like containers and servers, Ramon, where does React come in? And I'm so glad you asked, because I'm going to show you just a very short demo of running WebAssembly modules in React in the browser.

Hold on, this is Rust. Yes, yes, yes, bear with me. So what we have here is using the Wasm Bindgen crate or package declared and published a function to add two numbers. It takes two parameters, A and B and returns their sum. This is what the package equivalent for Rust called the cargo toml file would have with the Wasm Bindgen dependency. Then we can use a module, a package called Wasm pack to build that WebAssembly module targeted to the web. Then we're done with anything that we haven't seen before.

Back in React, now I can import, as you see in the second line here, I can import that add function that I have declared and compiled, and then use it as you see where it says this comment, call the WebAssembly add function. I can add those two numbers and then use them in React. But this is just a setup. Let's see the payoff. Boom, there it is. Now I'm using a module. Remember, a module that was built in WebAssembly in the browser. I'm essentially running Rust code in my browser. But cool. That's the browser. What about the server? And that's the thing. It's a server, isn't it? So we can use it as we would any other server. At that point, it becomes an implementation detail, which is what I was getting at earlier about how we don't really learn WebAssembly as we would React, for example. It becomes a tool.

So my friends, that's it for me today. Here's the link to my slides. That's ramonh.dev forward slash react dash wasm dot PDF. Please get in touch. You see my mastodon at the top right there. I'd love to hear from you. And that's it for me. I wish you all a wonderful rest of your conference and a wonderful rest of your day.