Say WAT Now!? Turbocharged JavaScript With Hand Crafted WASM

Hey, and welcome to my talk, Say What Now? Turbocharged JavaScript with Handcrafted Wasm. Let's get into it.

Take a look at this chart. Starting on the left, we've got Lua, Dart, Ruby, working all the way to the right of all these different programming languages. And on the far right side, by far the most programmers in the world are JavaScript programmers. Have you ever wondered why JavaScript was so successful?

Okay, before I answer that, real quick, my intro. I'm Justin. You can follow me on X, and I consider myself an open-source creator. Some projects that I've worked on are FormKit, which is a form-building framework in the Vue ecosystem. Arrow.js is a small, lightweight, reactive framework. AutoAnimate does automatic animations on your applications. Tempo is a datetime library, sort of like Moment.js. Drag and drop to make your drag and drops easy. And Vue.Formulate for the old days of Vue 2. But I'm going to get back into that question, why was JavaScript so successful? And I think that this is a really interesting question that has a few different variables playing into it. Certainly, if you look to the right-hand side of this list of developers, you have some of the easier languages to learn. Maybe not to master, but to learn. Things like JavaScript, but also Python is famously user-friendly. But I think the real reason why JavaScript took it is because of the browser. In fact, JavaScript is the only runtime in the browser, and has been for a super long time. Although I'm sure many of you know this, that's not entirely true anymore. Starting in 2017, which if you look at a calendar, is actually a long time ago. It's like a full five years ago now, more than that, six years ago now. WASM, or WebAssembly, has been also available as a runtime in the browser. And yet, we don't seem to use that much of it. What are its benefits? What's it all about? That's what I want to talk to you about. So first of all, what is WebAssembly? It's a virtual stack machine specification. Let me dig into this just a little bit more. So virtual, it's a virtual machine. That basically just means it's hardware independent.

You build it once and you run it everywhere, right? That was always the promise of Java back in the day. And frankly, it's one of the promises of JavaScript. You write your JavaScript and you can run it in the browser, you can run it in Node, you can run it all over the place. You don't need to worry about, you know, hey, is this a 64-bit or a 32-bit CPU? Is it running some particular chipset that doesn't work with the way that I compile these binaries? It's not like that. And Wasm is not like that either. It is a virtual machine that you can run anywhere.

Now, how about this one, stack machine? That's probably a little bit less familiar to people. And we're going to get into this a little bit more. But essentially, this is the computation model. Every machine that does computation needs a way to do that computation. You know, the sort of maybe the most famous one might be a Turing machine. But there are other computation models, like a register machine, which is what most assemblies are written in. This one's a little bit different. It's a stack machine. We're going to look into that.

And then finally, it's a specification. And that's actually maybe the most interesting part, is there's no canonical implementation of Wasm. Instead, it's a specification that anybody can comply with and have done so. There's browser runtimes, but there's also runtimes, you know, you can run Wasm in Node.js. And now you have systems level runtime. So you could compile your Rust binary, not just to run in the browser, but also to run as a system utility running in Wasm. So you don't have to compile to all the different binary formats. All right. What does it actually look like? Well, fundamentally, this is a binary format. So here's what it looks like. It looks like a bunch of binary code. But if we were to take this, this is an actual application you're looking at here. And in Wasm, all bits are 8 bits, or all bytes are 8 bits. So we could translate this into hex, for example. And we could see a little bit more resolution.

You can get some pattern matching out of here. If you're really clever, you might even recognize some ASCII code characters. And so, like, what if we do that? Okay, let's put it in ASCII. Interesting. And now we're starting to see a little bit of this application. But you still can't see or understand what these dots are. Those are undefined in the ASCII range.

So let's use a tool here. This is Wabit, or Rabbit, which is the WebAssembly binary toolkit. And you can go get this on GitHub. It's created by the WebAssembly team and allows you to convert between binary and WebAssembly and back into this new format that we're going to talk about called WAT. You take your Wasm file, full of binary, you run it through here, Wasm to WAT. And you just output it, and you get a string with the code, the assembly code, that actually made up that file.

And look at this. This is almost human readable. Let's take it one step further, and let's actually just add some conventions on here. You can see it says local get 0, local get 1. We can actually use a syntax to give names to those things. And now we have something that does look downright readable. Let's look at this file a little bit. So here we have a function, func. Okay, I think we can all understand what's happening here. And this function is exported as the name, add. We'll get to this later, but that's how we access it in JavaScript, is by the name that it's exported as. Not too hard to understand. And this function is going to take two parameters. It's taking parameter a and parameter b, and we can see that they're both typed as i32.

If you've done any systems level programming in Rust or any other language, you'll be familiar with i32. This is a 32-bit signed integer. And then down here we have a result. So the result of this is also going to be a number, another 32-bit integer.

Now let's get into the body of the function, and here's where that stack machine context comes into play. On the right-hand side, we have our stack. And what we're going to do is we're going to put something onto the stack here. So here we say local.get a. That's going to get parameter a, and it's going to put it on the stack. You have to imagine this in your mind a little bit for how it works. We're going to get parameter two here, or b, and that is also going to be added to the stack. So now we have two numbers in memory on our stack. And then finally we're going to run a function on top of what's in our stack. So in this case, i32.add. And i32.add consumes exactly two stack variables. So our a and our b in this case are going to be the input to that, and they just pop off the stack. So i32 consumes those and then returns its value, which is another i32, back onto the stack. That ends up becoming the return value, and that's it.

I think if you sit down and you actually look at this, you'll see it's not that complicated. And this was a big surprise to me. This was a big surprise to me that Wasm or WebAssembly text format was surprisingly human readable. Compared to, I would say, almost any other assembly language that I've read in the past, this is very human readable because it gives you the ability to have all of these nice human readable labels. So what we can do then with our file is we can pump it into the reverse command line tool that we saw before. This one is Watt to Wasm instead of Wasm to Watt. And we give it our Watt file and it pumps out a Wasm file. And this is what actually will run in your browser. And to do that, it's not that complicated. I'll show you three quick ways here. We've got WebAssembly instantiate streaming. And then you can just use the native browser fetch to go fetch the Wasm file.

And then it returns a promise that when it resolves, gives you the instance of that module. And then you can see here, you can say instance.exports.add. And that is our add function that we exported. And this works fine. Another way you can do it if you're using Vite, they've added this parameter question mark init. If you do that with a Wasm file, you can actually just directly import it into your JavaScript if you're using Vite and they'll do all of the hard work for you. And then this is perhaps the most interesting way to me. You can actually just base64 encode the Wasm into a string and then automatically or very easily translate it into an unsigned 8-bit integer array and then pass that into the WebAssembly instantiation and it will actually run just fine. And this is interesting because all the other methods require a separate file and this one doesn't. It just lets you run. Why would you actually do this? Well, most people are using Wasm to compile from Rust or C, C++, even Go down into the WebAssembly so they can run those languages in the browser. And that is by far and away the most used way to do this or to run WebAssembly, to write WebAssembly. And then even perhaps more interesting is people now want to compile into WebAssembly so they can run it on any OS and any chipset. That's all very well and good and interesting. But I'm actually more interested in just writing JavaScript and running it in the browser. But wouldn't it be nice if we could splash in just a little bit of WebAssembly to accelerate things? I think so. So anything that's a super hot path in your code, canvas rendering stuff, game optimizations, anything that's CPU intensive, you could have a small amount of handwritten Wasm and you could run that directly from your JavaScript code just as a way to accelerate, pour a little bit of fuel on the fire. I want to give a shout out here to Austin Theroux. I think it's how you pronounce his name. He has this incredible, unheard of little project that he did called handcrafted Wasm. And I actually want to show you just a couple examples. So these are all Wasm files that he wrote himself. You can come in here and you can look at it. So for example, here is a Lorenz system he wrote and here is the Wasm. And if you go and look at this, it is, again, surprisingly readable. It is really not too hard. But you can get some incredible performance drawing things on a canvas. So for example, I really like this Conway's Game of Life that he wrote. And I can guarantee you we are not even getting remotely close to hitting any kind of limit on performance here for my simple CPU. So definitely go check this repository out. He did a really great job.

All right, that's it for me. I'm out of time. Thank you so much. If you'd like to follow me, you can at JPShrader. And that little QR code will take you to my website. Thank you so much.