Liam: Imagine a world where developers can collaborate in the language of their choice, and interact with the components of their choice. That would be, I think, a great opener, and then we need like the "bah." Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. I'm here today with Liam Randall and Bailey Hayes, both of Cosmonic. And Bailey has the added benefit of being on the steering committee of the Bytecode Alliance. Liam is the CEO of Cosmonic. Thank you for joining us today. Liam: Thanks for having us on, Eric, we're excited. Bailey: Thank you. Eric Anderson: I'm looking at the brain trust of WebAssembly, and we are going to dive into all things WebAssembly. And as we always do on the show, we start out with a quick explanation of what WebAssembly is to the extent that's possible and then dive into the history. So Bailey, Liam, which of you would like to tee off with the elevator pitch on WebAssembly? Bailey: I think Liam's the best at elevator pitches. Liam: All right. I'll give it a shot, Bailey. But you jump in and help me out. WebAssembly has emerged from a set of ideas that came about 10 years ago about, how could we bring other languages to the web? And it started with this crazy idea about transpiling code from C or C++ into JavaScript. And amazingly, this idea grew to become I think one of the most powerful ideas in computing today. And when we think about what WebAssembly is, we can start with the technical definition, which is neither web nor assembly. Talk about a poorly named standard. WebAssembly is a standard originally out of Mozilla that's stewarded by an organization called the Bytecode Alliance, which is a foundation much like the CNCF, whose aim is to grow and provide leadership, steward leadership for WebAssembly. And importantly, WebAssembly is then standardized by the W3C, so with HTML, CSS and JavaScript, it is the fourth language for the web. It's already supported in all of today's browsers, on server side applications, and can even be embedded into other apps. That doesn't really tell you what WebAssembly is. I think the easiest way to think about WebAssembly is to think of WebAssembly as the world's smallest virtual machine. Think of it as a tiny little virtual machine that you can use to ship source code to, that doesn't include any of the overhead or any of the additional dependencies that you might find in Linux, for example, shipping containers around. So it's different than some of the things that have come before, but equally powerful. Bailey, what would you add to that? Bailey: Yeah. I usually tell people that WebAssembly is a portable compilation target. So I write my code and I compile it to a .wasm and it's that exact same .wasm that I send around on the server side and the browser, everywhere, and that is very powerful. And most developers are familiar with the .exe or DYLIB, or anything like that, and so that usually clicks. I would also add that the Bytecode Alliance is working on building a foundational ecosystem and sort of that software foundation that people need to continue to build WebAssembly applications. So while the W3C is what is pushing forward the standards, you could think of the Bytecode Alliances as creating lots of different developer tooling and SDKs and thinking about how registries work, and all of the different things that you really need to create an ecosystem. Eric Anderson: There's two parts maybe to this thing. There's the specification of what a container looks like, what a unit of code looks like. Liam: It's called a module. Eric Anderson: This module, this .wasm. And then there's the thing that it runs on, the jvm, the runtime, and that applies here analogous to how I think of Docker, right? There's kind of two bits. Bailey: Yeah. There's tons of different WebAssembly capable runtimes. Your browser is really a WebAssembly capable runtime. There's also a runtime that's supported by the Bytecode Alliance called Wasmtime, and that one is really excellent for running server side applications. For example, within Fastly running different types of serverless workloads. So you see Wasmtime. But that is one of... Gosh, how many do you think they're out there at Liam? Liam: There's probably a dozen with maybe five or six really leading ones. WebAssembly is a Bytecode. And what's powerful is that you could choose to interpret this Bytecode in different ways. You could just in time compile it or you could ahead of time compile it AOT. And you might do this depending on where you were running WebAssembly. And there are different engines that are tuned for different CPU and operating system combinations. So think about if we have this universal virtual machine that's very tiny, we could ship it from really big servers where we've got lots of memory and processor power and we want to run tens of thousands of WebAssembly modules, or we might want to ship it down to really tiny things on the edge or we might want to do both. An example might be Amazon Prime Video. They did this incredible blog post where they talk about supporting over 8,000 unique devices in their ecosystem. And rather than have 8,000 unique build targets, they were able to use WebAssembly as an intermediate delivery tool that allows them to deliver source code that works in a performant and expected way on a variety of devices, think your MacBook or your Samsung television or your LG or Sony or whatever the manufacturer happens to be. WebAssembly is a really powerful idea that's captured the imagination of developers everywhere. And we're seeing WebAssembly show up all across, not just the distributed ecosystem, but all across the traditional cloud native ecosystem as well. Bailey: The Amazon Prime Video example uses another Bytecode Alliance runtime and that's WAMR, so shout out to them as well. WAMR supports many different targets including embedded devices. So that's another kind of example of, it's the runtime that figures out how to make it most optimized for a given use case. And the WASM compilation target, the portable binary doesn't need to change. It can be interpreted or ahead of time compiled. Liam: You'll find all these WA things in WASM, it's this continual never-ending pun. So WAMR is the WebAssembly Micro Runtime. It was originally out of this amazing team over at Intel that donated code to the Bytecode Alliance, but there are other engines as well. But WAMR and Wasmtime I think are the two biggest server side ones that are outside of the browser that are worth really digging into or researching for people that are just getting into WebAssembly. Eric Anderson: So to the extent we didn't cover bits of the history of WebAssembly, take us back. You definitely mentioned that this started as a web thing and it's grown outside of that. What parts of the history did we not capture from before? And then I want to personalize the story a bit given we have the two of you in the room. Tell us where your story kind of emerged with the WebAssembly stories along the way. Bailey: So I joined before WebAssembly was WebAssembly and it was with asm.js, which is a project that came out of Mozilla. The idea is that if we have a tiny subset of JavaScript that looks kind of a lot like assembler, there's a concept of registers and types can't change, that kind of thing. You have this pragma, you use asm.js. You basically make a promise that you're going to write a certain subset of JavaScript and then the browser's able to optimize that. And looking at it, you might think this might be the greatest hack of all time because it was brilliant, it worked. And we were able to take C++ and C code, compile it and run it in the browser. But it wasn't the fastest, but it worked which was the step one. People didn't really believe that it could work. But then we started seeing these applications like the Unreal game engine get compiled in it, so that's like over 2 million lines of C++ code that they were able to compile in and run in the browser. And there were other competing ideas for how things could be done like PNaCl. But because this seemed so promising and people started kind of really pushing it forward, Adobe was another one of the early adopters. I was working at a company called SAS and we needed it for not necessarily as cool as a gaming engine compilation, but data visualization. So it was pretty complicated and I was taking many existing C++ libraries and I needed them to run ... at the time we wanted to support HTML5, I don't even know if that's a term anymore. But that's what we were trying to do starting in around 2012. And by 2015, all the browser vendors got together and said, "You know what? This seems important. We can come up with a way that's not the greatest hack of all time, but really a supported language, a fourth language of the web." And that's really when the WebAssembly design began by 2019. But really, really before that. 2017 definitely you could ship things to production, you're pretty good. But 2019, official recognized and recommended standard from the W3C, which basically meant, "It's everywhere. Start using it now. We recommended it." So that was a really exciting time. I feel like in 2015 I had something that was working really well within Mozilla and then later in Chrome and it was very fast and I was using this tool chain called emscriptin. Emscriptin made it so that I could easily modify my existing seatbelt plus build and output initially asm.js, later a wasm. So the rest is history. That was my first entree, was from the web side of the world. But if you talk to the folks that were working on it even in the 2015 to 2017 time range, it was always really important to keep the semantics to be purely about designing this portable virtual machine. At no point was it like, "Let's get the JavaScript stuff all up in there." There was a really good separation. And even then while we were working on it, consider the properties of it needs to download extremely fast, maybe even have a streaming compilation so that it's compiling while it's being downloaded. It needs to have a really tiny footprint because again, we're talking about now a web and also cloud native world. And that means that we're distributing all this kind of stuff and it needs to be really tiny, so super small footprint. We also need it to run fast. Like, "Hey, if we are already supporting JavaScript, people can work with that, that's fine. But what if we can make something that's faster than JavaScript? What if we can enable all kinds of new workloads?" So if we're getting something that's near native that downloads incredibly fast, compiles incredibly fast and is super tiny- Liam: And secure. Bailey: ... and secure, right, because you're working for the web, the web lets you download arbitrary code from anybody. If you've got all of these properties bundled together, I'm really just describing a cloud native workload that's distributed. And so even around that time people started saying, "You know what? This could be pretty interesting for a lot of different things." Liam: Think about the landscape that we were living through at the time, Eric. At the time, a number of major technical companies had tried to seize this landscape, to bring a fourth language to the web through plugins and their own proprietary approach, Microsoft Silver Light, Adobe Flash, even some of the Java embedded stuff when you think about the nightmare of the plugin world that we used to live in and the security disaster that followed. WebAssembly is powerful because like many things in open source, when things are free and you're just competing on developer experience and value, you get radical innovation very quickly. And WebAssembly emerged as a collaboration point where if you look at the members of the Bytecode Alliance now, you'll find some of the biggest names in tech alongside little startups like Cosmonic, ours, that understand that this is the next epic of technology. At the time, I had created one of the first, if not the first Kubernetes company in 2014 called Critical Stack, and it was acquired by one of our customers, Capital One. It was in a rocket ship, and I had an amazing time at Capital One helping to move a hundred million customers and about 5,000 applications into the cloud. And along the journey of building the first cloud native bank, we recognized how many opportunities there were to do things better. And the most frustrating problem that I felt we had was that developers would spend 80% of their time on operations and maintenance. And when you think about what that means, that's all of the steps that are embedded in today's containerized workflows. Even when we try to hide them behind platform engineering or advanced DevOps, developers have 95% or more open source that they pull in to build their applications. They'll start with a template. Companies love their developers and they want their developers to be productive, so they'll give them a template with all 95 enterprise boxes checked. The problem is that when we embed all of those requirements and tightly couple them into the application, developers then own the maintenance on those and they end up spending significant amounts of their time. So along with my co-founder Kevin Hoffman, we were exploring a number of technologies to solve this problem. At the time I was VP of innovation and Kevin had started working on a new book. He's written like 25 tech books. And we came across WebAssembly, we started doing some pilots. But we got really excited around the concepts for building a server side framework for WebAssembly. And it's now today one of the fastest growing projects in the CNCF. It's called CNCF wasm cloud. And it is a framework that helps you to get started and adopt WebAssembly in your organization that embraces many of the concerns of enterprises and developers. It really leans heavily on this WebAssembly standard called the component model. And what that is it sort of treats your application as a series of Lego blocks that you can use to plug in things like web servers and databases and key value stores and other common components without pulling all the source code into each app. To us, it really started to feel like the future because when we built it, we started to have, one, customers and community members like Adobe and BMW come out of the woodwork and start telling us how excited they were and doing demonstrations. We even published a case study with Adobe recently in the CNCF called Kubernetes and WebAssembly: A Better Together Story to help people understand that WebAssembly is different than what we're doing today. And that's where it's powerful. It's not going to replace containers, it's going to complement containers, especially as we think about the next 10 years of development. Eric Anderson: Awesome. It is fun that you both have these kind of personal ties to the history and Liam, I think we kind of heard when you realized the magic of WebAssembly. Last question, Bailey, did you have a moment as well when this turned from like, "Oh, this is a cool way to run C++ in the browser," to like, "I actually might be changing computing here." Bailey: It's more like the moment that keeps happening. I feel like every couple weeks I see something new that just totally blows my mind. I'll just list a few because I think they're all awesome and worth looking at. In our pre-call, I told you I was going to say this, I knew I was going to find a way. I really love how the Microsoft Flight Simulator found a way to make it so that you can modify it by passing in a wasm module instead of some random dll that you got to install on your machine. That's a really great case where maybe you could find ways to containerize it, but Windows, docker containers, not always great. So finding a new way of being able to make it so that I can download mods and not be totally terrified that I'm going to blow away my machine is super important to me as a gamer. So that's one. That one was definitely like, "Wow, yeah. We're really, really onto something here." Adobe's use case that Liam mentioned, I felt that was really an interesting way of doing signatures, but the kind that you normally think where you're... I'm waving, and I realize this is a podcast, but writing out a signature, like the physical kind of writing a signature and validating those, I think that's really, really interesting. So if you can do that, what can't you do? There are some current complications where we don't yet expose all of the different capabilities that we want to be able to use within the component model. Liam briefly mentioned this, but it's the idea that if we maintain this really tight sandbox, then we want to be able to provide plug-able capabilities. So if you think about when you're in your browser and you see whether or not you've given access to your microphone and your camera and all of that, consider those capabilities. For a wasm module running server side, that might be access to a SQL database or a key value store- Eric Anderson: Or a file. Bailey: Yeah, exactly. And so we're building out all of these different contracts, they're really standardized APIs, to let the WebAssembly runtime know how to safely expose those and how the wasm module itself can say, "I depend on these standardized things." And that way we can still maintain the portability, but also the security model. And so I think the combination of those two things is really cool and critical. When did I think it was going to be a thing? Before 2015. But the reason why we were trying to do this, actually I was at a at CPP con and it was actually the Dropbox talk, they had the exact same problem we had. And then you look around the room and everybody's like, "Yeah, we kind of solved it this way too." And it was, "Oh geez, everybody's doing all these mobile devices now and I need to support an iPhone. I need to support Android. This Windows phone might be a thing, we don't know." And so there's all these different operating systems, all these different architectures. And how the heck do we support it? And so everybody just basically came to the conclusion that was like, "Okay. Common denominator for everybody is C. We'll start there and then we'll build up all these different platforms around it and then have all these very specific native builds for each one of these platforms." And then you had this kind of separate epic of computing in the mid 2010s, maybe 2016 ish where everybody's like, "Okay. Maybe we'll just make it all Electron apps because that was really hard." But the entire time I was like, "You guys, we could be doing this in wasm and it would just work and we can run it literally everywhere and we only have to build it once." So I was having that the whole time. Every single time somebody brought that up, I was like, "Wow, we're doing it the hard wave. But I realize the easy way doesn't quite exist yet. But I really, really want to see it." Liam: Yeah. Look, I think what's amazing about WebAssembly is how you see it showing up throughout the landscape in so many unexpected places. And I would really say there's three big use cases for how we see WebAssembly, but they're not really any different from each other because they all derive from the same core value props of strong sandboxing, portability, and capability driven security. But the first is obviously some of the ones we've mentioned around applications running in the web, huge value prop, and it's really blurred the lines between server side and web side components. In Adobe's case study, they talk about a microservice that edits images and how oftentimes it was easier for them to push the microservice down to the browser, which wasn't something they could do when they were dealing with the four gig container image that they needed to scale. The second big use case is pure server side, things like what Cosmonic's doing where you're writing microservices and developing applications like you would on Fastly or CloudFlare. And the third is I think a little harder for people to wrap their brains around. It's as an application plugin. And when you're looking at people like Shopify or service mesh like Envoy, where people used to in the past, give you Lua or a scripting engine, today we're saying, "Here's an API. You can customize this with WebAssembly." Or more often they're hiding WebAssembly behind some simple API, which is what you see on Shopify and CloudFlare and Fastly for example. The magic behind all of these experiences is this new standard for the web. And what really blows my mind is that we're going to see business models change based on the power of WebAssembly. When you think that you can now leverage the distributed computing to build new peer-to-peer business models or business models where developers or users are bringing more compute instead of just their eyes, this really opens up a whole radical new type of application that I think we're going to see develop over the next few years. And we're honestly humbled and excited to get to play a small role in helping to bring other people to this amazing community. Like a lot of early stage communities, it reminds me of Docker and containers and Kubernetes in 2014. Everybody has this real positivity and enthusiasm and we know that we have some hard problems to solve. But having just come out of a meeting working on roadmap for the year, we have just some really exciting things ahead for the next 12 months. Bailey: We keep mentioning the component model, but that's really the main work that we're trying to do right now within both the W3C from a standards perspective, and then from building all of the right tooling for that within the Bytecode Alliance. And so what we're actively working on this year is really all the different pieces and parts that will make up WASI Preview2. So WASI Preview1 has been out for a few years and that is really, WASI, the WebAssembly Systems Interface is really that capability driven piece that we talk about about, "Hey, give me this handle and that handle will allow me to access a file system," for example. And so WASI Preview1 was very much focused on making it so that you can write a function that maybe runs as a CLI, the kind of initial things that maybe you would expect out of libc. Now we're thinking at a higher level of those APIs. For example, a lot of ones that we mentioned before, WASI SQL, accessing a SQL database and a key value store and messaging and logging and all these others that we want to make both standardized from a security perspective, but also portable because they're standardized. And so that falls into WASI preview two. But a different side of that is that we also have what was once called the interface types proposal. But now we're just kind of scooping that all up and saying the component model. But the idea is that if I component-ize something, rather than create a WASM module, I create a component. My component has different capabilities that it needs, and the way that I interact with all of those is through an interface of the different functions that I export and the functions that I need to import. Those things might actually just be contracts that are really the WASI APIs that we talked about like WASI SQL. And the way those are implemented and provided to me by a host, say I'm running on an embedded device versus running server side versus running in the browser, that could be really different at each one of those stages. If I'm in the browser and my setup is something that is for local, but I want to be able to have some kind of local cache, maybe give me index CB access from the browser. But if I'm running on an embedded device, I'm really constrained on memory and I need to send that off to maybe some external store. So what that allows us to do is have the ultimate flexibility with a capability security model. So all of that type of work from the interfaces and how that works with creating this new component ABI, so that .wasm is really now going to be a component, that is the work that we're working on. I would also say that we're seeing tons of different languages come online. I know that was one of the things that Liam kept talking about the most when we were getting ready to go to the airport. He was just like, "Man, I just saw a JavaScript. I've seen PHP, I've seen Ruby, I've seen Python. This is so exciting to finally get all of these dynamic languages on board because before, a lot of people were like, "Oh, it's just Rust and C++." And now we're seeing a groundswell across all the top 20 languages. Eric Anderson: These components, should I think of them as dependencies? In the future, whenever I say import whatever, I'm just going to be pulling in WASM components? Bailey: So that's a great question. In the world of when you were building a WASM module, they were definitely dependencies that you compiled in. Now what we're trying to say is, what if you let the host figure that out for you? You depend on these things, yes. But it doesn't mean that that shows up in your WASM artifact. That means if I say everybody starts embedding a JavaScript runtime and the JavaScript runtime itself is this one WASM component, a host could be smart and be like, "Yo, I am a WASM runtime. I don't need to embed that. Just give me your code." That will be an option. You could say that JavaScript dependency is a dependency, but it's really something that you just need to import for your component. Liam: Let me offer a more lay analysis of this as well. If we think of WebAssembly as the World's Smalls virtual machine, how WebAssembly is different than containers is containers are very tightly coupled to Linux. A container is a very good virtual Linux desktop and with that means that you can easily move things that are tightly coupled to Linux, libraries that you depend on or apps. You can have some portability. WebAssembly releases those dependencies. Kelsey Hightower in this talk we hosted called it the new computer. But what that also means is that we don't have things like the rich libraries that you would normally find on Linux. So think of WASI, which is another one of those words, it started as the WebAssembly System Interface, as the Lego blocks or the libc. Or I know Posics isn't really an in vogue comparison, but the library that we can use of raw building blocks to build your app. And this year, your Lego blocks, your kit is going to get new pieces that lets you automatically model common cloud components like a key value store, SQL. And then underneath that you can hot swap or replug those like plugs and ports. So you could move from Postgres to MySQL to Azure Cosmos DB. Those are things you can do on WASM Cloud, which supports something like a very early version of this now today for developers to start using. And that's going to be incredibly powerful as we enable not just those Lego blocks, but the ability to use those Lego blocks across languages. So you could start with components that have been written in very performant and memory safe Rust, and then pair those with user code that's written in Python, for example. And we just saw this demo that two amazing engineers that Fastly did, Guy and Peter. Peter Huen and what is a guy's last name? Do you remember? Bedford? Bailey: Guy Bedford. Liam: Guy Bedford. Bailey: Yeah. Guy is spearheading the JavaScript component effort and Peter is heading up Cargo component, which is the tooling to make it really easy in Rust to make components. Liam: And they just did this amazing little demo that was a two by two. "Let's have these two components access each other from JavaScript to Rust, then from Rust to JavaScript and back and forth." And it was one of those very simple demos that maybe someone might see on tomorrow's Bytecode Alliance community call Bailey, hint, hint, wink, wink, that Bailey will be running tomorrow at 8:00 PM Eastern standard time, 7:00 central if anybody's interested. And this talk will actually already be out so you can find it on the YouTube channel by the time that you have a chance to listen to this. But it's one of those demos that when you see it, you understand the power of what you're seeing and that this is really going to change the world. Eric Anderson: And then what other question I've been kicking around is are we really going to get to all the languages? Bailey, you already teased at this. I heard somewhere some FUD around garbage collection. Do we have line of sight to all the languages you'd want? Bailey: Yes, finally. Trying to solve how to come up with a generic way of doing garbage collection. We have garbage collection proposals in phase three of the WebAssembly proposal phases. So there's I want to say five, but four basically means it's everywhere. And so three means we're starting to see it in browsers, we're starting to see it in some other WebAssembly run times. And so you can really get a good feel for it. It helps solve a lot of the problems that we need for JavaScript for example. But we're also seeing many other languages come onto the scene that aren't necessarily dependent on the garbage collection proposal. They're doing some of their other work. Maybe some of the FUD you saw as where people figured out how to compile in their garbage collector into the WASM module. That is a common strategy that I've seen and it works. It's a larger size. So there's a trade off. The size can be larger. Maybe the performance isn't as good compared to something that began its life as a Rust or C++, but it's not as bad as people make it out to be. I've used a lot of that stuff and it works really well. The one thing I wanted to highlight back on Liam's last point is if you can imagine now a world where I could use the best tool and library for the job. So if somebody writes once this really awesome Regex library, when I used to work in the Go ecosystem, having to pull in Cgo was like lava. Everybody hated it. Nobody wants to pull in that C library. It's such a pain. You see this exact same thing from the JavaScript side of the house to the Python side of the house. Everybody really just wants it to be in their language ecosystem, which means that we built up all these different silos across all these different ecosystems and we're rewriting and redoing the same kind of tools that are pervasive across the industry. And so imagine a world where we break down all of those walls and I can depend on any other piece that's from a front-end engineer, backend engineer and that we're able to actually collaborate and build on the same building blocks as each other. So that's the future I see. Our language is showing up, we should answer that question. Liam: Eric, I think you've got the best movie voice. Could you movie voice that for us? "Imagine a world where developers can collaborate in the language of their choice and interact with the components of their choice." That would be I think a great opener. And then we need the bah and then the puddle shaking back and forth. Or maybe it'd be a Mountain Dew bottle or something. I don't know. We'd have to developer it up. But I'm on Jurassic Park. I think you're following me here. Eric Anderson: Our producer in the background is like, "Oh man, how am I going to pull this off?" Liam: "How do we cut this out?" Eric Anderson: Right? I think what you highlighted, maybe both of you, Liam, Bailey with this cross language thing is I was kind of imagining we should be thinking of, where are unique places that we've wanted to run code that we haven't been able to easily like the browser or the edge where we're going to see wasm emerge? But you're pointing out that everybody wants to use libraries from other languages. And if that's the case, then we just need wasm everywhere. Bailey: I'm here for it. Liam: It's even more amazing than that. When you look across the market today at where people are investing, people are moving up the stack from this Home Depot model of computing where you would build your own cloud towards these interfaces that are like the electrical company. I give you my coding, you just take it and run it. And we see Fly.io. We see Vercel with their isolates. The amazing thing is that regardless of what technology you're working on, for example in JavaScript, there's actually two different ways to do JavaScript in WebAssembly now. One is based on V8 isolates, so that's like the Google Drive tree. And the demo that we just saw last week that Guy Bedford was working on is SpiderMonkey. So underneath the hood, that's the Mozilla sort of underlying engine. But what I love as somebody that really cares deeply about the developer experience is choice. And I think that when we've seen ecosystems that enable collaboration and are open source, WebAssembly is in this Cambrian explosion of ideas right now in use cases. And it's just I think the most exciting place in tech to be right now. It's even more exciting than AI in many ways. Eric Anderson: So how do I get some of this component goodness today? You guys are working on this. Do I just need to follow Bailey on Twitter and wait till she says it's all ready to go or- Liam: I think that what we're trying to do with our open source framework that we contribute mainly to is a CNCF WASM cloud. And even in the way we originally created and curated its steward leadership, we put it into the CNCF because we are about enabling shared and transparent governance. And one of the commitments that we've made to our community as some of the leaders of this org, but we have steward leaders from Google and other companies on the open source project as well, is that as the standards emerge, we continue to update the framework to adopt them seamlessly. And web assemblies moving so quickly right now, I think that many of the ways that people will take advantage of this power is through frameworks like CNCF WASM Cloud or Cosmonic, which is the company that we work for that's sort of like the batteries included experience for WASM Cloud or through Fastly or through CloudFlare. And it's an easy way to get started today. But I think it's important to understand that as an enterprise there will be those enterprises that understand the power of WebAssembly and adopt it sooner. And they'll be like Figma or Shopify, which are two companies whose whole product experience pivots around and is enabled by WebAssembly. And when you understand that it's going to be the early movers into WebAssembly could achieve the same kind of business impacts that the early movers into the cloud achieved. They're able to franchise out whole areas. Let's imagine for a moment a bank that's able to adopt WebAssembly. Banks have their tendrils and hooks into thousands of different places throughout the economy. They're in some ways banking platforms when you think about all the different interoperability and code that they enable. Imagine offering core banking services that could be customized with WebAssembly where we now have a secure and performant way to share an interchange code, anything's possible. Bailey: So here's the engineering hat. Hey, we're really working on WASI preview2 right now and that's when the component model is fully realized. We're a handful of milestones away from WASI preview2 being for real. There are plenty of prototypes out there and that's the one that we keep mentioning, the one that we're most excited about where somebody took Rust and JavaScript, separate components and did a smoosh and made them work really well together. But that's still kind of all on unstable branches and that kind of thing. So if you want to come join me and be on the bleeding edge, all of our work is happening mostly in the Bytecode Alliance organization. Wasmtime's one of those early run times. I definitely recommend checking out Wasmtime. It also has a really good documentation, so that's the one that I point most people that are like, "Hey, I just want to figure out service side wasm." That's that's a good place. If you're trying to write applications, and Liam alluded to this, we have wasm cloud and wasm cloud has an SEK. And within our SEK, we're doing our best to sort of throttle this rapid iteration of changes, but still bringing in the open standards as they come along. So that's a good place to join if you want to be on the bleeding edge, but you don't want to get cut by the bleeding edge. That's a good place to be. Fastly, CloudFlare, lots of companies and Microsoft even are iterating on all of these different spaces and a lot of us are coming up with the same kind of like, "Let's give you an SEK that's stable and then iterate as the standards come along." Liam: Yeah. I would mention Microsoft just launched a new runtime called Slight, and there's another wonderful company out there called Fermion. They have a runtime that's called spin. And for the embedded use case, if you're looking to embed WebAssembly into your application, there's a company called Suborbital and they've got a runtime that really focuses and specializes on that. And we are all nominally in the same competitive landscape. But when we dig down to the details of how broad we all expect WebAssembly to be, we're very collaborative. We all collaborate, work together all the time because we understand that raising awareness and educating people about the opportunity of WebAssembly is the rising tide that truly lifts all boats here. Eric Anderson: Awesome. Liam Bailey, we have been through the whirlwind of WebAssembly and I feel like we've only scratched the surface. We may have to have you come back for a 12 part series or however many it would take. Thank you so much for coming on the show. Any final comments? Bailey: It was great being here. Liam: It was great being here. And Eric, I think the one thing that I love is the boundless enthusiasm and optimism that we have with WebAssembly is really because we get to work with so many amazing people in the community. Not just at the companies that we've mentioned, but if you take a look at the BCA, the Bytecode Alliance webpage, even within the CNCF proper folks like Chris Aniszczyk over there, there's a lot of us that have been in and around through many of these last epics of tech over the last 20 years. And we all share the same excitement for WebAssembly. I'm just excited to keep you up to date and the listeners as well. Eric Anderson: Thank you both. You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.