 So, my name is Bailey Hayes and I am a principal software engineer at Singlesore and today I'm going to give you a bird's-eye view of the WebAssembly landscape. But first we're going to do a little brief history. So it's 2012 and I realize that I have a need for Wasm, but Wasm doesn't exist yet. We have a very large code base, that's a data visualization library, and we're already found a way to take portable C++ code and run it in a number of different clients, both in desktop environments and in mobile. And now we want to find a way to do that with the Web. And that's where we enter with what I believe is the greatest hack of all time. It's my opinion, but if you guys have other great hacks, please tweet them at me because I want to know. But personally I think Asmjs, which is a subset of JavaScript, and around this time was pushed forward by Alonzo Kai and other Mozilla engineers, and it let us take C++ and basically transpile it to a little bit of JavaScript and be able to run that in the Web. And that really started an evolution. It wasn't perfect, so if I'm going to pick on somebody else for the greatest hack of all time, I have to give one of the ones that I put into production, and that was this try catch finally block. It was actually an intern I was working with at the time added finally at the end, and this was the last thing that made our code work in IE because we were running out of memory trying to jit our Asmjs, and so this kind of forced it into an interpreted mode. So hacks all around. So with Asmjs, we proved a point that there was a need. There was more than just games that were interested in running real code in the Web, computationally intensive code in the Web. And that's when a number of the browsers and vendors got together and pushed forward a specification, WebAssembly, and that design phase started in 2015. Basically the moment it was available in any browser, we began compiling to it with a tool called M-scripten. And by 2019, it's a recommended Web standard and officially the fourth language of the Web. Now, we're all here at Wasm Day, so I assume that you know a little bit about WebAssembly, but just in case you're not lost for the rest of the day, I'll give you a quick definition. And the way that I think of it is that WebAssembly is a compilation target. It's portable, it's language agnostic, but more than anything, we always have running jokes here at these different conferences, and for the rest of the week, you're going to hear jokes about YAML because of Kubernetes, and so I have to say this. WebAssembly is neither Web nor Assembly. Even in 2015, we knew that we were targeting something that wasn't just for browsers. That's really surprising to people given the name, and I would say that around that time, we didn't quite have the term Cloud Native. I actually looked it up. And Wikipedia in 2019 was when Cloud Native became kind of a more common term. The CNCF, I believe, was founded around 2015, so we could have ended up with WebNative as our term, for example. So I don't think it's that bad of a name. Now, because WASM is portable, this is what we were kind of thinking even in 2015 for the problem that I was talking about, that I was trying to solve. I have an application, I have to deploy to a bunch of different targets. Those targets, I have to have specific platform bindings for each one of those, so it's almost like I'm writing my own little runtime that's specific to my application on every platform, and I'm compiling to each of those, and that's incredibly expensive. And then for each one of those projects, we had separate teams running each one of them. Now, what I would love to see is being able to compile an application once, to WebAssembly, as a common compilation target, and then have the run times be something that's sort of managed in an open way that's common across many different applications. And so I told you I was going to give you a bird's eye view. These are supposed to be eggs, but this is kind of that exact same diagram, but in terms of a matrix, because I think if you're somebody that is interested in cost, you're thinking about what is your build matrix, what's your test matrix for all of these different things that you have to support. And I think a lot of us have probably recently felt the pain of having to support ARM. For me, our container is x86, and that didn't run on ARM at all. The virtualization wasn't working. But for many other people, it was just the case that it wasn't as fast. And so you needed to add more to your build matrix. Containers did help us with some portability aspects, but I think really what we would love to see is kind of the holy grail of having one egg solved for each one of our applications on the server and the browser and in the edge. This is one other thing that I feel obligated to show. This is an off-quoted tweet from Solomon Hikes, who's one of the founders of Docker, and he said that if WASM and WASI existed in 2008, then we wouldn't have needed to create a technology like Docker. This ruffled some feathers, and so you might be wondering what is WASI. Well, WASI is, I think of it as really a part of the runtime. It's a set of interfaces. In some cases, POSIX compatible interfaces that allow WASM modules to run well outside of the browser. But one interesting take that's not just pure POSIX, like we could have just ported all the POSIX APIs and been done with it, but that would have really broken a lot of the promises of WebAssembly, the safety, security, and portability aspects of that, and so it's capability-based by design. And what that means is that, say, for example, one of the early things that were ported is being able to access environment variables. And if I wanted to have a driver program and it has access to EMVs, then only a set of the keys that are exposed to my WebAssembly instance are available to me via WASI. And to compile to WASI, it's really simple. You typically, in any of your top-level languages, you have a top-level target. This case is Rust, and in any target, WASM32, WASI. Now, it's still early days, and so there are a lot of proposals that are in flight for this. It's one of the areas that I think everybody in this room can help with the innovation in the space. One other thing that I do mention is that there is no networking protocol yet that's been approved for WASI, but there's a really interesting take on this, which kind of pushes the work into the runtime via WAGI. So long as your runtime is WAGI-compatible and your WebAssembly module meets some of those contractual pieces, then you are able to do networking style work, and I think we'll get a few more talks about that today. Now, I keep talking about the runtime, and the reality is that there are a lot of them. There are 20-plus runtimes that are out there. There are many different compilers because working on performance is fun, but more than anything, there are also many different platforms that are cropping up for WebAssembly. A lot of these are really interesting to me personally. I think that there are new evolutions on new types of computing paradigms, and it's incredibly exciting. As far as languages, well, there are a ton of them, so I'm not going to list them all. I think, again, it's about 20-plus. But if you have a component language, and that's your favorite language, while you're in luck, it's very likely that that has already has support for WASM. The reason why I wanted to touch this slide specifically is because there's this common misconception that you have to write and rest to be able to work with WebAssembly, which is kind of hilarious for me, because obviously my original case was C++, and that's what I've been bringing forward all along. But I would say even in 2015, C++ and C, we're still the main things that you were able to use with WebAssembly because WebAssembly and its precursor, Asmjs. And that's largely because M-scripting built off of the LLVM tool chain. Now, obviously, Rust has had an amazing complement with WASM. They've really grown and supported each other. And if you think about it, a lot of the things that are really nice in Rust and a lot of the things that motivate developers to use Rust are really similar motivations to use WebAssembly, memory safety, and amazing developer tools, and portability. But there are going to be other talks later today that will cover some of these other languages. And I just want to see more. I think we're all really excited over the past two months to have seen Python and Ruby both gain WebAssembly support. Now, I added a C in front of these, and that's because it's taken the C interpreter. And that piece has been what's been compiled to WebAssembly. Now, there are a few WASM specific languages, like Grain and AssemblyScript. For AssemblyScript, I'm going to call that out specifically, because it is also, you would say, an interpreted language. If you're not familiar with AssemblyScript, but you are familiar with TypeScript, you'll find using AssemblyScript is really nice, because the syntax is very similar. But one key difference is that AssemblyScript is ahead of time compiled. I think that's really compelling and really interesting, very innovative. What we've been seeing is a lot of interpreters get compiled to WASM, and not a lot of scripting languages getting ahead of time compilation. So I'm really looking forward to seeing the innovation that happens in this space going forward. Speaking of innovation, what's next? Well, it's the component model. This is really a proposal in the space of WASI. It's building on top of some of the other proposals that have gone through. The idea is that it's a language-neutral approach to building WebAssembly applications, and you're able to build them on top of each other, like branches, if you thought I was done with the bird analogies, you don't know me. And so, as you're able to build many different WASM modules on top of each other, we can do something that's really incredible that hasn't been done before. Have you ever experienced the situation where you're working at a company and you're mostly invested in one language? And you go to your boss and you say, hey, I found this library, it does exactly what we need. I don't have to write all this code. Can we use it? And they say, well, am I gonna have to enable the Seagot flag? And he's like, well, yeah, maybe. And they say, no, we can't do that. Let's port it or let's come up with a different solution, maybe something that's a little bit slower. Or say you're working at a Java shop and now you're introducing something that has to operate over JNI. And so many cases were separated by our language ecosystems. And more than anything, that silos us as developers in each layer of our stack. So something like the component model can really mix things up and change things for the better. So before I was talking about this giant matrix that you have of applications by operating systems and targets to just having one single compilation target. But now imagine that I've really exploded that sandbox, right? Because now if things support the component model, we can get to the point where we have access to millions of different tools. If that excites you and you find it interesting, I recommend pushing your company to join the By Code Alliance. It's pushing that proposal and many others forward. If you're an individual contributor and you're interested in working like in the W3C, which is pushing for the WebAssembly specification. Or you just wanna get involved in the community. The place that I linked here is Wasm Builders. That's a really great place to get started. Now, we're gonna enter a part where I think is a little bit more of my opinions of the WebAssembly landscape. But we'll start with a really simple one. These are terminals that are written in Rust. When something is written in Rust, it's sort of a no-brainer to make your plugin model be something that uses Wasm because Rust and Wasm are so complimentary to each other. But there are cases that are incredibly surprising. Like Microsoft Flight Simulator is a game and it allows mods of the game with Wasm. An older version of this used DLLs. So if you can imagine somebody's able to hack a game, what are they able to do to my computer when I install it and give it full access? But there are also very standard production examples. I really like the Figma example here because with Figma they actually started with JavaScript. It's really common when you're saying, okay, I wanna come up with a plugin model. You typically are gonna look at maybe Lua or JavaScript or some other scripting engine and they started with JavaScript. But due to some security issues, they ended up landing on WebAssembly for sandboxable capabilities. If you're interested in that, I recommend checking out their engineering blog. It has a fantastic deep dive. Now, we're here at CNCF, so you're probably already familiar with these two projects. Envoy is a side-core proxy. There's a cloud-native computing foundation project called Wasm Proxy that lets you extend Envoy so that you can write your own HTTP filters and transformations. But what I find so interesting about this case and also in the Open Policy Agent case where you're able to write custom policies is that we're really moving the computation that you need right next to where you need to run and come up with that decision. I think that's one of the trends that we're gonna start seeing more is near data processing. And hopefully that gives us better performance, but more than anything, it means that we didn't have to move that data out over a network request, so we're getting data locality as a bonus. Now, I'm not an expert in this space, but what's been explained to me is that smart contracts run on the blockchain. And once some set of conditions has been met, the smart contract executes, any computer that's participating on the blockchain, like that could be your own desktop, can execute that smart contract that's gotta be safe and secure in Sandbox. Well, to me, that's a plug-in. And so all of these so far are really, in my mind, different ways of writing plug-ins. Now, a lot of people don't think of data processing as a plug-in system, but there are several out there already, in my opinion. Red Panda, which is obviously the Red Panda here, and Infineon are both data streaming engines, and they allow users to pass in their own transformations of those engines, and to basically bring arbitrary code and run in those systems. The database that I work on is Singlestore, but there are many others that are finding ways to add user-defined functions using WebAssembly so that we're pushing that compute down to the data. SilaDB is one, TIDB, and many others. So this is a term that we're starting to see crop up more often when people talk about WebAssembly, and so this is like the case that I work on, which is compile your code to Wasm, using whatever language is supported, and then using a single SQL statement, you say create function, and you pass in your Wasm module, maybe over an HTTP URL. But what's so interesting about this is that, because we take that Wasm module and we're a distributed database, we now are able to move it across many nodes in our stack. So in a lot of ways, this is another distributed computing problem, but all of the properties that make Wasm amazing in the browser, like being lightweight, and fast, and scalable, and being a very tiny footprint, and format makes it perfect for these types of distributed computing problems. Now, I live in North Carolina, so you might not know this bird, but he lives in my backyard. I took a picture of him, and then I drew this picture. It's called a woodpecker, and the woodpecker that's in my backyard is constantly trying to break into my house, and so I thought he was the perfect analogy for talking about security. So why is Wasm secure? Well, we already kind of know some aspects of that. Wasm modules only have access to the interfaces that they've been granted from the host runtime, and they don't trust the code that they're executing. But that's not the interesting part here. The interesting part is thinking about all the trends and pressures that we're experiencing as an industry, and how that's gonna really push people, I believe, to Wasm. The first one being that software supply chain attacks are increasing every day, and finding ways to mitigate all of the different vulnerabilities that we have across our hundreds of dependencies for applications is gonna be key. Wasm is a really interesting take on that approach. For example, there's a methodology that Firefox employs that is very novel. It takes basically parts of their application stack, compiles those to Wasm modules, and then takes those Wasm modules and runs them eventually in machine code. So what it means is that it mitigates entire swaths of zero-day vulnerabilities for a single monolithic application. So it's really, in my mind, taking the way that you write applications and twisting it to be sort of like a plugin model within your apps. So by the end of this year, the majority of us will have almost all of our customers under some type of privacy law enforcement. GDPR started it, but there have been many others that have come afterwards. I believe Liam's been pushing this idea several times now. I haven't heard a lot of other people talk about it, and I think it's really key when we think about how and where we store our data. With WebAssembly, we are very explicit about our memory model, and who shares what and where, and so the capability-based design of Wasi, I think, is gonna be really key in considering things like privacy law. So when we think of a new technology stack, we typically have a set of applications, maybe one or many that are talking to each other over REST services, over some kind of network. Maybe they're hitting AI and ML inferencing over some type of cred-rest endpoint. They typically have many different libraries. They're connected to many different data sources. They're running across many different devices, typically deployed in some type of orchestration across many different operating systems in theory. So my question to you is, where would I write only one language? Anywhere in this stack do I expect only one language to exist, ever? Probably none of these. Probably I want portability in each layer of this stack. Obviously everywhere we need safety, security, and performance, but when we think about what are the things that each layer of the stack actually need, we know that we need many different languages, many portability, safety, security, but also just being fast to download and start because it's not just one tree, it's a forest. Now, I can't predict the future, but to me, when I look at the modern technology stack, what I'm thinking about is how WebAssembly is gonna be at the top, the middle, and the bottom of whatever this new thing is. And because of that, it really means that Wasm is cloud native. So let's talk about the next area with serverless and functions as a service. Now, I believe that one of the main reasons why this hasn't been as popular as what I originally expected it to be is because of cost. At the end of the day, we were still running the same amount of compute and memory needed to run a specific task. But with Wasm, we really have an interesting take on how to vastly reduce our cost for these cases. So because Wasm starts faster than containers, because it's lighter weight and has a smaller memory footprint, and also because we're able to actually scale it to zero because it is so fast. In many cases and functions, we have to already have some pre-warmed state of it so that we're able to service requests quickly, right? Because containers may take several seconds to start, but WebAssembly modules may take a few milliseconds, maybe even microseconds. But I think more than anything, that's gonna push people to enter our WebAssembly landscape is cost and what we know is that the cloud is expensive. It's given us a lot, right? We've been able to write in microservices, deploy faster, independent of each other, but people aren't gonna use our technology, the technologies that we create unless it solves problems. And one of the biggest problems in cloud today is cost. So let's talk a little bit about the feature. This is completely my opinions, and I'll start with a really aggressive one, which is, is WebAssembly gonna be the next default compilation target? Well, if you believe me that it is the last plugin model that you'll ever need, then Wasm really could be a default compilation target, especially for many languages. Obviously the languages that directly support WebAssembly as a first language, but I expect many others. Now, if you believe that, then you might believe that WebAssembly is gonna kind of push people to consider writing applications more like a plugin. I gave the Firefox example earlier, but in my mind, serverless and FAZ are really kind of an interesting take on what it is to be a plugin. So when you're running a FAZ service or a serverless managed service and you're accepting other people's code and you're running it in your infrastructure, you have to make sure that it's sandboxed in some way and it can't impact other users. To me, again, that's a plugin. So I think in a lot of these cases when we start seeing more Wasm, we'll see kind of this, I'm considering just an extension of the plugin model. And if that's the case, then we know that you're almost always gonna be guaranteed a WebAssembly runtime at every layer of the stack. If you know that, then what we're really talking about in the space of innovation, it's really the future of runtimes as a whole. And if we're there, well, do we have one package manager to rule them all? No, we've been trying that for a long time. We just introduced new ones. I don't expect that to be the case, but I do expect package managers to start serving WebAssembly because many of our top-level languages now support Wasm and can pull them in and link against. So we're already seeing this really with NPM, but I totally expect even in this year to see several more. So with the component model, we're gonna finally get universal language and library support. But we'll also see because of that, the democratization of our software, we will be able to work with every layer of the stack because they're able to finally interrupt between each layer. It's no longer the case that you're a front-end engineer and you can't use a really interesting Rust library or you're a systems-level engineer and somebody wrote something in Go that you wanna be able to use at a lower level. I think something like this is really gonna make it so that it doesn't matter who and where you are on your skills journey, you're gonna be able to use the best component and library and tool for the job. And that's really exciting. And I think we're all here today so that we can push this technology forward. And I really encourage everybody to reach out in the community because birds of a feather flock together. Thank you.