So, I'm gonna be honest with you folks. I do a terrible job of staying up to date on the latest tech. I see things come up on Twitter, I see people talk about it, I add it to my list of things tto learn, and then I never get around to it. It's a vicious cycle. But, it's a new year, so it's the perfect time to break vicious cycles.

Earlier today, I saw a tweet about WebAssembly. I've heard a lot of chatter about WebAssembly over the past couple of years. I've skimmed through the WebAssembly website and even attended a talk on WebAssembly at a conference once. That being said, I've never really taken the time to dive into the technology and really understand what all the enthusiasm was about. Until today. So, why the heck is everyone talking about WebAssembly?

What?

Answering "What?" is usually a good place to start when trying to figure out anything new. The WebAssembly homepage provides this description:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

This description was definitely not written for people who wanted to learn about WebAssembly in a hurry. I did some snooping around to see if I could find an explainer article that was a little bit more approach. I recall that Lin Clark produced some pretty good content on WebAssmebly so I decided to see if her introductory article would be a little bit more helpful.

I found that her intro was pretty useful. It confirmed that my assumption on what WebAssmebly was was true. WebAssembly is a way to take code in any programming language and run it within a web browser. OK. That's a much more approachable definition and I can immediately see the value of a technology like that. Now, how does it work?

How?

While the "What?" is an interesting question to answer, the "How?" is even more interesting. Anyone who knows me (or has read my previous blog posts) knows that I like to get very nitty gritty when exploring how things work. I figured that for this, I'd start by writing my own program, compiling it down to WebAssembly, and then running it in the browser.

I found that WebAssembly's introductry documentation was a lot more approachable than some of the text on their landing page. I followed the directions under the "Downloading the Toolchain" section. They instructed me to clone the Emscripten SDK and install it on my local machine.

$ git clone https://github.com/juj/emsdk.git
$ cd emsdk
$ ./emsdk install latest
$ ./emsdk activate latest
$ source ./emsdk_env.sh

Much to my surprise, absolutely nothing terrible happened as I ran these steps. That's right. Nothing went wrong when getting set up for something new! What a pleasant surprise.

The next step was to write a "Hello, World!" program in C and compile it to WebAssembly. Once again, the steps under the "Compile and run a simple program" section of the Developer Guide.

So, what essential happened. I wrote a program in C and compiled that program using the Emscripten toolchain. This Emscripten compiler generated a Wasm source file, a JavaScript file, and an HTML file. The HTML page loads the JavaScript file which in turns loads the Wasm source file onto the page. Since I'm using a recent version of Chrome browser, the compiled Webassembly in the Wasm source file is run by the browser.

The WebAssembly program is represented as a plain JavaScript object, aptly called Module in the codebase. This Module object is generated in the javaScript file generated by the Emscripten compiler and stores information about the memory used within a WebAssembly program, the Wasm binary associated with the program, code to manage the runtime status of a program, and more. Essentially, this module encompasses the data and code of a WebAssembly program and can be sent to wherever you need a WebAssembly program to run (like my browser). You can find more information about WebAssembly modules in this design doc.

Why?

Now, why WebAssembly? One of the most popular reasons that came up when researching this question was WebAssembly's speed.

Although performance is an important factor for any technology, I don't believe it's the most important factor. I've seen far too many developers sacrafice other important factors (like developer experience and maintainability) at the altar of performance when it wasn't necessary.

To clarify: I'm not dismissing the benefits of WebAssembly's speed in certain contexts. I'm just looking for more pros.

What else does WebAssembly offer? Well, the other obvious big perk is that it expands the types of programs (and by extension programmers) who can deliver their applications through the Web. I can't understate the value of this. It's an interesting premise. I'm curious to see how this will change how people develop on the Web and what impact WebAssembly

The reasons above are compelling for WebAssembly as a technology in general, but I'm curious to know if I might be able to use it directly in the contexts I'm working in. I spend most of my time these days doing full-stack web development with React in the front-end and Node in the backend. I found one rather compelling and interesting use case for someone like me.

From the "How?" section above, you'll recall that WebAssembly runs compiled code within the browser. Because this code is compiled, it has undergone a certain amount of obfuscation.

Despite these, there are still ways to get around this obfuscation. When I was researching this, I came across this paper that discussed ways that compiled WebAssembly modules could be deciphered. When there's a will, there's a way.

Why not?

No technology is perfect. After exploring some of the reasons for WebAssembly, I decided to see if there was any reasons to avoid WebAssembly. What are the shortcomings of WebAssembly?

This was a surprisingly difficult question to answer. I suspect that because WebAssembly is a fairly new technology, it hasn't achieved the criticial mass necessary to spot any bumps or kinks in the technology. Or maybe WebAssembly is flawless and perfect and has absolutely no flaws?

I will say, it would've been a little easier to find reasons not to use WebAssembly before major browsers adopted the technology by default. The fact that Firefox, Chrome, Edge, and Safari all support WebAssembly. All that being said, here's a couple of the things that I've noticed while researching Web assembly.

From the "How" section above, you might recall that the C source code that I wrote was eventually converted to a Wasm binary that was loaded onto the webpage and executed by my browser. There's a whole new asset (the Wasm binary) that needs to be sent down the network to my browser. As with anything that is sent down via the Internet to user's browsers, care needs to be taken to minimize the size of the binary so that it doesn't slow down page load times. This isn't a downside of WebAssembly, per se, just something to watch out for. It's not like this problem doesn't exist with non-Wasm assets on the web. And from my research, it seems like quite a few people have written articles on how to minimize the size of these binaries so shrug, this might not actually be that big a deal.

Another cumbersome issue that I came across when researching WebAssembly is the interpolarity between WebAssembly and JavaScript. For example, how do you invoke a function written in JavaScript from your WebAssembly program (in whatever language it is written in)? I found a Medium article that discussed a work around one developer used and a proposal for allowing the WebAssembly modules that I described in the "How?" section above to be imported like ES6 mdoules.

So yeah, I guess, for the most part the "Why not" for WebAssembly is that it's a fairly new technology and not all the details have been figured out. But from what I read, the champions of the community seemed pretty proactive about responding to issues and creating design proposals for problems so there's that.

Conclusion

Alright! That was a pretty fun exploration. I'm glad that I'm a little bit more confidently informed on what WebAssmebly is. I don't imagine myself using it any time soon, but I think that's because I'm not working in a situation (building 3D games, etc) that would benefit from using WebAssmebly.

Are you currently using WebAssembly? Do you have concrete plans to use it in a feature/product you'll be shipping soon? Did I misunderstand anything about WebAssembly in this blog post?