 Hey everyone, thanks for tuning in. Today, I wanted to talk to you about WebAssembly, what it is, why it's awesome, and how you can start using it in your own web applications. So let me start by introducing myself. So my name is Robert Buquilio, and my background is a mix of software engineering and bioinformatics. I'm the maintainer of the library Biowasm. So this is a collection of bioinformatics tools that we've pre-compiled to WebAssembly and are hosting for free on CDN so that other bioinformatics web apps can make use of it. I'm also the author of the book, Level Up with WebAssembly. So if you're just getting started with WebAssembly, feel free to check it out. All right, so what is WebAssembly anyway? Well, I like to think of WebAssembly as really just being yet another language that you can use in the browser alongside JavaScript, HTML, and CSS. Now, to give you a sense for what this language looks like, let's take a look at a simple example. Here I'm defining a function called hello, and all this function does is return the string openJS world. Now, you don't need to know anything about WebAssembly, just looking at this. You can tell this is not a language that you probably want to code, and that's good because you don't have to. In fact, the whole idea of WebAssembly is that you can take code written in other languages and compile that down to WebAssembly. And so that's why it's called a compilation target, because you take code written in these other languages, compile it to WebAssembly, and then you run it in the browser. So where is WebAssembly actually useful though? Well, here are a few use cases. One is code reuse. You know, all these applications I'm showing here are very large code bases, hundreds of thousands, millions of lines of code. Where WebAssembly was really essential to let them transition these apps from running on a desktop or in a command line onto the web without having to rewrite everything in JavaScript. So this is very convenient from the code reusability perspective. The other big use case is performance. So in these four applications, what they've done is look at the most compute-intensive part of their apps that were written in JavaScript and replace those with WebAssembly. And what they noticed was a large speedup and better performance. Now, of course, so I know this is not guaranteed to work, just because you use WebAssembly does not mean that your app will always be faster, but for a certain category of data-intensive applications, it can help. The other use case behind WebAssembly is portability. So the idea here is that you can also use WebAssembly outside the browser, really anywhere where you can find a WebAssembly runtime that can execute your code, you can have WebAssembly. And so here I'm showing, for example, for example, Cloudflare and Fastly, these are providing serverless functions that run WebAssembly at the edge. The nice thing about using WebAssembly for serverless is that they initialize a lot faster and are cheaper because WebAssembly is a lot more lightweight than using containers, for example. You can also run WebAssembly on your server if you use runtimes like WasmTime, WasmR, or even Node.js can run WebAssembly. You can also run your WebAssembly by an Arizona Raspberry Pi as shown in this screenshot from the Wasm3 team, which also build a WebAssembly runtime. So all these use cases look great, but can you actually use it today? And the answer is yes. About 93% of users on the web today are running browsers that support WebAssembly. And so this is great news. One thing that's interesting, though, is how many developers actually use WebAssembly? And so to get a sense for that, what we can do is look at the state of JavaScript. This is a survey that's done every year. They pull 20,000 JavaScript developers. And one of the questions they ask is, are you familiar with WebAssembly? And so here are the results. About 75% of developers who answered this survey know what WebAssembly is, but had not had a chance to use it. 15% have never heard of it. And only about 10% of the respondents for that survey said that they had actually used WebAssembly. So we only have two data points here, 2019 and 2020 for the percentage of developers who have used WebAssembly, around 10%. But if we're interested in projecting future WebAssembly usage, what we can do is use very sophisticated mathematical modeling techniques to try to impute what is the usage going to be in the future. And so what we can see is by 2047, over 100% of JavaScript developers will be using WebAssembly. Now, I'm kidding, of course, that's not how anything works, but it will be interesting to see how that number actually plays out over time. All right, now what I'd like to do is concretely give you two examples of applications that I had the chance to work on where WebAssembly was really useful, both in terms of performance and code reuse. So the first one is FastQBIO. This is an interactive WebTool that lets the user input DNA sequencing data and rapidly evaluate the quality of that data while the data stays inside the browser. So when we set out to build this, we kind of looked around and there were several tools that could help calculate these statistics that we're interested in, but none of them were written in JavaScript, right? So we have one in C, C++ and Java. And at the time that I built this, I hadn't really heard of WebAssembly. So we figured the only options were, number one, host one of these tools on a server and expose an API that lets you make custom queries to that tool. And while we could have done that, that gets expensive real fast, especially if you have a lot of users that need to scale it up. It's also problematic because you need to make sure that it's secure and it doesn't accidentally let users execute arbitrary commands on your servers and start mining Bitcoin. But also there's a data upload issue, right? The main use case for this application was to analyze files that were already on the user's local computer. And so this would be inconvenient to have them uploading the data to the cloud before they can even analyze it. So the second approach would be to rewrite a part of these tools in JavaScript. A few problems there as well. One, this takes time, obviously. Number two, it's error prone, right? Anytime you're rewriting a complex algorithm that has edge cases, you're gonna likely introduce errors. The other thing is that we're now maintaining a separate copy of this tool written in a different language. And so we won't be benefiting from all the updates and all the bug fixes and new features that get added onto those original tools. So despite the challenges, we ended up going with option number two. So we rewrote a small portion of the tool, CCTK in JavaScript, and it worked. However, then I came across WebAssembly and that's when the third option opened up. And this is really where WebAssembly shines. Like these are all existing tools that are written in languages other than JavaScript that we can now compile to WebAssembly and run directly in the browser. So not only do we get to run it in the browser, but there's also no need to rewrite any of the code. So we get the best of both worlds. What's interesting here is also that on top of the code reuse that we got, we also saw some performance improvements. So what we are able to do is actually speed up the app by 20X by switching to WebAssembly from our JavaScript implementation. So if you want all the details for this, you can check out my Perf Matters 2019 talk on YouTube. All right, case study number two. So this is an app that's called Ribbon. It's an interactive tool, lets you explore complex rearrangements in genomes. Part of this application involves parsing a special bioinformatics binary file format. And to do this parsing, we have a few existing tools that we can use, written in C and Rust. Again, this is very often the case in bioinformatics, by the way, where a lot of the tools are written in C and C++ and Rust and so on. And so here we kind of end up with the same situation, right? In terms of implementation, do we host a tool on a server? Probably not, same issues as before with the cost of security and uploading the data to the cloud. The other option being rewriting it. This time, however, it won't take us much time because someone else had actually already rewritten portions of SAM tools in JavaScript. And so we just ended up using that. But after the success that we saw with FastQ Bio, we figured, well, let's try WebAssembly here as well. And so what we saw was, again, interestingly enough, we saw a two to three X improvement in terms of runtime. But probably even more important than that we're now able to reuse 100,000 lines of very complicated C code that parses unique genomics file formats. And what's really nice about that is that we're now able to use features that are available in the C library, but we're not implemented in the JavaScript one. For example, we can now do a very quick check on the validity of the file formats. We can down sample the data randomly to reduce the amount of memory that we're using and how much compute we need on the user's computer. And all of these are only possible because we're just relying on the off-the-shelf tool that we've compiled to WebAssembly. All right. So if you're building these kinds of data intensive web apps, there are several interesting tools that you can use with WebAssembly. And one is threads. Obviously a lot of tools use threads to speed up execution. And WebAssembly does support threads using web workers and the way that shared memories implemented between threads is using this thing called share array buffer. However, with the Spectrum malware that showed up around 2018, what happened was that browsers ended up turning off support for shared array buffer until relatively recently. And so a few years later, we're still at about 70% of users running browsers that support shared array buffer. So we're getting there, but we're not quite all the way there. And so if you are using threads, it's probably a good idea to use feature detection where you test, does the user support share array buffer then use WebAssembly with threads otherwise use the version of the WebAssembly binary that does not have threading in it. Another really powerful tool is SIMD. So SIMD stands for single instruction, multiple data. And the idea is that this is a way to parallelize code that is very commonly used in data analysis, image processing and so on. And so the idea is as the name suggests, you can process multiple data sets within a single CPU instruction. So just to give you a very concrete example, let's say you have points in a three-dimensional space and you're interested in calculating the distance between these points using this formula. So here what you could do is calculate these three subtractions one after the other, therefore taking up about three CPU instructions or you could use SIMD and insert those coordinates in an extra large CPU register that can fit four of these numbers at a time and do the same for the second data point. And then what you can do is use a SIMD instruction that will subtract all three coordinates within a single CPU instruction. So obviously this has a lot of potential for speeding up the calculation, which is why it's so commonly used in a lot of mathematical and data analysis heavy tasks. And the reason why I mention SIMD is because there is a WebAssembly SIMD proposal currently focused on 128-bit registers. For most browsers, this isn't actually supported unless you enable a flag, but it will be enabled by default in Chrome 91. Now I recently did a test drive of WebAssembly SIMD. What I wanted to do was essentially align DNA sequences to a reference genome and benchmark the runtime with and without WebAssembly SIMD. And what I found was really, really interesting where as you can see the WebAssembly with SIMD gives us pretty close to the native SIMD performance but in the browser, which is really fantastic for those applications that can benefit from SIMD. And what's really interesting about this is that when we compare performance between JavaScript and WebAssembly, one can always argue, well, you didn't optimize your JavaScript enough and it's not because of the WebAssembly that your app is faster. And that could be very true, but when now we're talking about SIMD, this is a whole new game because JavaScript does not have access to SIMD instructions whereas WebAssembly does. And so this is why this is a really, really exciting advancement. I'm looking forward to seeing that enabled in all the browsers. If you're interested in learning more about WebAssembly SIMD in particular, you can check out my recent WebAssembly live talk that is available on YouTube. All right, so so far, I focused mostly on how awesome WebAssembly is, but before we end, I do wanna spend a moment talking about when you should not use WebAssembly. So to me, it kind of comes down to three things. If your app is not compute-intensive enough or it's too compute-intensive, or if WebAssembly adds too much complexity to your code, then you should not use WebAssembly. And so I wanna just dive into each of those a little bit deeper. So first, if your app is not compute-intensive enough, so if it doesn't involve graphics, if it doesn't involve data processing, simulations, audio processing, video, image, you know, all these kinds of compute heavy tasks, for example, if you're building a CRUD app, just use JavaScript. That's kind of the idea here. At the other end of the spectrum, if you're trying to do too much compute-intensive work, it's just not gonna work in the browser whether you use WebAssembly or not. You know, for example, if I'm trying to assemble very large genomes in the browsers, it's just not gonna work, right? I'm gonna need to deploy that in the cloud where I can have more hefty compute power. And finally, you know, code reuse and performance are really nice and all, but it's also important that we consider the complexity that WebAssembly adds to our code base, to our build process, but also to the maintainability of the code for your entire team, right? It's a bit hard to give concrete examples here because this will really depend on your team and how comfortable they are with introducing something like WebAssembly, but at the end of the day, WebAssembly is a really powerful tool. You just have to make sure that the added complexity is worth it for your application. All right, so that's all I had to share. Please check out my book. If you're just getting started with WebAssembly and you're looking for a practical guide, I also have a whole bunch of other articles and videos that you can check out. And with that, I wanna thank you very much for being here.