The State Of WebAssembly - With Lin Clark and Till Schneidereit
Lin Clark and Till Schneidereit from Mozilla discuss the current state of WebAssembly and WASI.
Lin and Till talk about why even a front-end developer would use WebAssembly, which leads to a discussion on one of the primary use cases of WebAssembly, performance optimization. They also get into the nitty-gritty of WASI, or the WebAssembly System Interface, which allows WebAssembly to be used outside of the browser.
Kent C. Dodds: All right. Hey everybody, this is Kent C. Dodds, your friend. I am joined by two friends, actually. Lynne Clark, and Till... I actually didn't ask your last name. I'm so sorry. What is your last name Till?
Till Schneidereit: It's Schneidereit.
Lin Clark: Yes.
Till Schneidereit: Yes.
Kent C. Dodds: "WASI", yes. Web Assembly System Interface, right?
Lin Clark: Correct.
Kent C. Dodds: We're going to chat about that, and get some ideas there, but I want to get to know you, each of you, first, a little bit, especially if our listeners haven't heard of you yet. So, Till, why don't we have you go first? Can you introduce yourself to us?
Till Schneidereit: Sure. I work at Mozilla, where I'm the Manager of the Developer Technologies team. My team is working on Rust, the language and the compiler, and WebAssembly tooling. So, not the WebAssembly execution environment in Firefox, but the tools for compiling to WebAssembly, for example, and also WebAssembly web times outside the [inaudible 00:01:35], and this WASI initiative that we just announced last week. Our part of that is developed by my team.
Kent C. Dodds: Very cool. We're definitely looking forward to hearing more about WebAssembly outside the browser because it's like, wait, what? So, it's going to be great. I'm looking forward to chatting about that. Lynne, why don't you introduce yourself?
Lin Clark: Sure. I'm Lynne Clark, and I make code cartoons.
Kent C. Dodds: Yes!
Lin Clark: Thank you. I also work at Mozilla. We actually work in the same team, Advanced Development, and so I work closely with the WebAssembly folks, and the Rust folks, and basically have been focusing on WebAssembly for about the last two years, since it's been on by defaulting browsers.
Kent C. Dodds: Thank you for that. You failed to mention one really important fact about yourself, and that is your unique skills at karaoke, and getting everybody to join you.
Lin Clark: That is on my resume. I'm glad that you reminded me to point that out.
Kent C. Dodds: Code cartoons is fantastic. It's such a great way to teach people new concepts. I love that as you've made this transition more to a systems-type stuff that you've carried that with you, because it helps people like me, who I really know much about that, to really at least understand at a high level what these things are doing. So, thank you for all of that. So, great! Let's talk about WebAssembly a little bit. I think it would be really useful for people to get kind of a history of what WebAssembly even is, and especially the "why" behind WebAssembly. Why does this matter? It's typically really helpful for people to understand what this thing really is, and how it works, and what role it plays in their lives. Can one of you give us kind of a brief history of WebAssembly?
Lin Clark: I think there are a whole variety of different instances, or different cases, where you could benefit from WebAssembly. So, one example that one of our engineers at Mozilla figured out how to rewrite the source maps parser. The source maps library, it's used in Webpack, it's used in our developer tools. It has a parser that was rewritten in Rust compiled to WebAssembly, and that parser is now, I think, 11 times faster after rewriting it. The WordPress projects rewrote their parser that runs in their online editor in WebAssembly, and I think that's 86 times faster on average? So, in these cases, where you have things where the code gets called a lot, it's not maybe as fast as it could be. You're getting some problems with the execution speed, a lot of times that makes sense to write to WebAssembly. There are a whole bunch of other cases too, but that's the one that I think most web developers are interested in, and acquainted with.
Kent C. Dodds: Hmm. Yes. So, like, solving performance problems, and our web applications.
Lin Clark: Yes. There is one other case though, and Till, you might be able to speak to this.
Kent C. Dodds: That's bonkers to me. I actually had a question about that, that I've been wondering for a long time. What's the story of WebAssembly, and its interaction with the "Dom"? In a scenario like that, where we're taking an entire application and compiling it to work with the Web, I imagine that the tools that that application used natively before don't really work quite as well on the Web. Like, we have a different API for the UI side of things. So, what's that story like with WebAssembly?
Kent C. Dodds: Right.
Kent C. Dodds: What?
Lin Clark: Yes.
Kent C. Dodds: Right, yes. It's not just the performance question either, but also the tooling around that, and all that stuff. So yes, I think ... and now, analyzing the actual costs is, you know, that's kind of a programming thing. We're always ... cost benefit analysis on everything that we do, hopefully. Hopefully, we're doing that, and not just falling the next shiny object.
Till Schneidereit: There are some use-cases where it's just very obviously the case that either the performance won't matter, because the data you are upgrading on is so small that whether you have this string [inaudible 00:17:33] cost or not, or the computation costs, it really doesn't matter. Or, if it becomes relevant, then doing it in WebAssembly is obviously the right choice.
Kent C. Dodds: Mm-hmm (affirmative).
Till Schneidereit: So, in those use-cases, like the parts are, as Lynne mentioned earlier, going with the WebAssembly route just takes the headache away of [inaudible 00:17:53] it.
Kent C. Dodds: Yes, yes. That makes a lot of sense. So, WebAssembly, as we've recently been hearing about, it's not just limited to the Web. It's actually ... you know, we can take WebAssembly out of the browser, which makes WebAssembly kind of seem like a misnomer of a name, now, at this point. But, this is how the Web eats the world. It's the technology and the Web just, it's everywhere now. You can run node on anywhere now.
Lin Clark: Exactly.
Kent C. Dodds: Let's talk about WebAssembly outside of the Web. First, a little bit about the "why would you care to do this?" and then, I've got a couple of other questions to understand its' place in the Web. Can we talk a little bit about what this WASI thing is all about?
Lin Clark: Sure. WASI is the web assembly system interface. It's an effort that we are leading to standardize a system interface for web assembling. I will explain a little bit about what a system interface is. When you are running code on a machine, you don't want to let applications just rewrite files Willy Nilly, and just access memory, and so, the operating system sits in between, and when your application wants to do something, it has to ask the operating system instead of just doing it itself. The way that the operating system makes these services available, the functions that it gives your application in order to be able to do these things, that's the system interface. But, WebAssembly ... so, when you're compiling your code, you'll say what kind of machine you're targeting, what operating system you're targeting, so that your code knows which of these implementations of the system interface to use based on what platform you're targeting.
Kent C. Dodds: Now, we're talking about the chips that the hardware is using and things like that?
Lin Clark: More like the operating ... so like actually saying that you're targeting a Mac, or you're targeting a Linux machine. The problem here for WebAssembly is that when you're compiling your code, you don't yet know what operating system you want to run on. You know, that's this portability thing that we have with WebAssembly. We want this WebAssembly file to be run across all different kinds of operating systems, so we need to not just target a single system interface. We need a conceptual system interface. Something, just as WebAssembly is an assembly for a conceptual machine, you know? It can run across all these different chips that you were talking about, all of these different machine architectures, because it's this conceptual assembly that sits on top. We need a conceptual operating system and we need a system interface to target that conceptual operating system. And so, that's what WASI is. One of the nice things about it is that, because we're developing it now, instead of 40 years ago when a lot of the other system interfaces started being developed, we can bring some of the most up to date concepts from systems into the design of this system interface. So, it actually takes a new approach to security, which has been studied in academia for the past four years, but only has recently gained any kind of traction in industry. We can bring that to the system interface, so that we can have really fine grains sandboxing and security controls.
Kent C. Dodds: Oh, very good. Yes, that makes a lot of sense. So, this WASI kind of ... or these implementations, are these basically like a virtual machine like the JVM, and that kind of thing? Is that kind of what it's basically like?
Lin Clark: Yes. Runtimes can use WASI, and then we can have a lot of the same properties of the JVM. I think Til probably can speak to that.
Till Schneidereit: Yes. There clearly are some commonalities with something like the JVM, or Microsoft.net common language, runtime, or also scripting languages like Python or Ruby, which also bring this virtualized environment with them. But what these all have in common is that they're, let's say, highly opinionated. They are optimized for a specific language, or a specific set of languages, in the case of the JVM or the CLR, and have fairly high-level memory models, for example. The byte code is just for, in the JVM case for example, how you optimize for Java. With WebAssembly, we have something that's much more much closer to other ... to actual CPU architectures, and thus allow you to target this runtime using a wide range of different languages, and also allows it to scale to use-cases from tiny embedded sensors, up to large server farms with the same kinds of [inaudible 00:23:30]. Perhaps when using a different runtime, because different runtimes can be optimized for these different use-cases, but you can target them with the same tool chains, and with the tool chains you are used to, because you're using them for other things. For example, as of today, using a nightly compiler, you can use target WASI with Rust, without anything special at all, just by telling the compiler, "Compile this to WASI," instead of as a Meco [inaudible 00:24:02]. Our big goal is to enable people to target this environment with the tools they're already using, and still cover this wide array of use-cases. Really opening up new worlds for people, without them having to learn a whole new language, or a whole new runtime system.
Kent C. Dodds: Hmm. Yes, that's a really interesting. As a primarily front-end engineer, I do plenty of Node as well, but it seems like this WASI side of things is more targeted to people writing native code that's going to run on servers, or on IoT devices. The idea is I want to be able to choose my language of choice, and then have the one ... you know, the build artifact be able to run on any platform. Is that kind of the goal of WASI, then?
Lin Clark: Well, you know, I think that WASI can actually help a bunch of different use-cases. It can help a bunch of different run times. You will have run times that are meant for those kinds of people who aren't really involved in the Node ecosystem at all. But, we're also talking to the folks in the Node project about how they can use WASI. I don't know if you've ever had to do native module development? I'm sure you've had to use a native module at the very least.
Kent C. Dodds: Yes.
Lin Clark: With native modules, the reason why you have to compile, when you have no GYP running, when you're installing an application with the native module ...
Kent C. Dodds: Yes. Half the time, it doesn't work and you're like, "Oh! Duh!"
Kent C. Dodds: Yes. That makes a lot of sense. So, is that future ... clearly, we need to have the WASI implementation installed on my computer to run WASM files. Am I understanding that right?
Lin Clark: Actually, no. Node would have it baked in, basically.
Kent C. Dodds: Right.
Lin Clark: So when you install Node, you'd have it already there for you.
Kent C. Dodds: Cool, yes. That's exactly what I was going to ask. Awesome! And so what that means is, if a language like Ruby were to compile to a WASM file, and then that gets published to NPM, as a WASM file, then I could actually run it on my machine, even if I didn't have Ruby installed, because it's actually running within a WASM. Is that correct?
Till Schneidereit: Yes, it is correct, but it is a bit more complicated because the language like Ruby ...
Kent C. Dodds: Maybe that was a bad example?
Till Schneidereit: For a language like C, C++, Rust, the answer would be just absolutely, unequivocally yes. For languages like Ruby, Python or Go, also ... so, Go targets WebAssembly. And in fact, a day after we announced WASI, someone had a work in progress, a working patch for Go to target, not just WebAssembly, but WASI specifically, and use that as the system interface for Go, which is really exciting. But to make that work, they have to bundle the Go runtime, because Go has a very sophisticated garbage collection system, and at runtime, that is sophisticated but also fairly large. And so, a WebAssembly module, a WebAssembly / WASI module, written in one of these languages, has to bundle that entire runtime, or have that runtime available, perhaps as an external module, at least. For a Ruby application or a script, that would mean having the Ruby interpreter essentially bundled with it. In fact, for Python, we have that. Another team at Mozilla taken the Python interpreter, and compiled it to WebAssembly, and that now runs on the client side for doing scientific computing tasks, which so far, only worked in service side installations. They compiled the entirety of the Python interpreter, and so, it's not Python code compiled to WebAssembly. It's Python itself compiled to WebAssembly executing Python code, unmodified path and code, and that's how this work would work for us [inaudible 00:30:15].
Kent C. Dodds: I see. Okay. Very interesting. So, that seems like potentially problematic from the size standpoint. This is the same thing with ... I remember when I was doing Java stuff, and I wanted to provide my users an executable that where they didn't have to have Java installed, like the runtime installed. I had to bundle the whole runtime into that dot exe that I sent to them. Okay. Yes, that's-
Till Schneidereit: One additional point on that. What is interesting here is you're right. People have to have these different runtimes installed. If you get some Python code groups on one, you have to have the Python interpreter installed, and potentially even multiple, different versions of it, because there is this Python Two versus present Three conversion that's been going on for a decade. Installing these can be a headache, and that is part of why this other Mozilla team took the Python interpreter compiler to WebAssembly. With WASI, you can imagine a future where these kinds of interpreters are compiled to WebAssembly, and really, the only requirement you have is for ... and so, to a new operating system, to compile or to run Python code on a new operating system, requires you to have it available on that system. One interesting thing there is you could imagine a future where the Python interpreter or the would-be interpreter, would be compiled to WebAssembly. Porting them to a new operating system, would be, well, your port the WASI runtime, and you don't have to port all software to these new operating systems. What really just ... you need the WASI at one time, and then these other interpreters for other languages just work by being compiled to WASI. Then maybe later on, you do a specific port because you want to have no overhead at all, but at least this would just work [inaudible 00:32:37] where wherever WASI is available.
Kent C. Dodds: Right. That makes a lot of sense. Cool. So, we're coming down on our time here. I want to encourage people to kind of get into some of this stuff. What resources do you have for people who are interested in learning about WASM and WASI, and trying to find places where they can actually implement this, or play around with it?
Lin Clark: For learning about WebAssembly, I have a series of code cartoons on the hacks.mozilla.org blog. I think that that gives a good intro to some of the concepts around WebAssembly. If you're looking to play around with WebAssembly, I really recommend the Rust to WebAssembly's working groups. They've done some documentation on how to compile Rust to WebAssembly that I think is really, really good. This is actually, I think, a lot of people are saying that the Rust user experience for compiling to WebAssembly is the best language, so far. So, I think that for people really just wanting to get started with it, that's a great starting place.
Kent C. Dodds: Perfect. Also, I am going to add a link to this, as well. The blog post announcing this standardization of WASI by you, Lynne, I thought it was really informative, especially the little demo video that you had there. So, I'll add links to those as well-
Lin Clark: Great.
Kent C. Dodds: ... and invite people to check those out.
Lin Clark: Thank you. I appreciate hearing that, too. I'm glad it helped people understand these concepts.
Kent C. Dodds: Mm-hmm (affirmative). Yes. Cool. So, is there any last things that you want to share with the audience before we wrap this up?
Till Schneidereit: Maybe one thing is we are just starting out with WASI, and if this is something that is interesting to you, then we have WASI.def that has more information. But, we are also starting the standardization process for this. In an online call tomorrow for the W3C working group, or community group Brand WebAssembly, we will [shadow[inaudible 00:34:51] a subgroup. If you think this is something where contributing to this effort would be interesting to you, then I'd encourage you to join that. Join us for the call. Join the subgroup, and get involved with that.
Kent C. Dodds: Awesome. Cool. Well, thank you both. Really quick, where can people find you on the Internet? Lynne, why don't you go first?
Lin Clark: Sure. So I am Lin Clark, L-I-N-C-L-A-R-K, on Twitter, and that's the best way to follow what I'm doing.
Kent C. Dodds: Cool.
Till Schneidereit: Twitter's also the best way to follow me, and I'm Tscheniderpride on Twitter. Maybe you can do the link to it?
Kent C. Dodds: Yes, we'll get a link. That's our show this time around, so thanks for joining me for this. This is pretty interesting, especially the WASI thing, is really interesting. I just love how the Web is eating the world, even outside of the Web, and I feel like WASI is a good step in the right direction. Especially if I can avoid Node GYP problems in the future. That would just be spectacular. So, thanks everybody, and we will catch you all next time. Goodbye!