WebAssembly allows developers to run any language in a sandboxed memory-controlled module that can be called via well-defined semantics. That might sound confusing, but we're going to get into it in this episode, and we discussed it in much detail in previous episodes with Lynn Clark and Steve Clabnick from Mozilla, as well as an episode a while ago with Brendan Eich. WebAssembly is changing application architectures both inside and outside the browser, so it's worth paying attention to. WebAssembly is being adopted by all of the major browser vendors, including Google.
Today's guests are Thomas Nautistad and Ben Smith from Google. Thomas is the PM4-V8, which is the JavaScript engine of Chrome. He's also PM for WebAssembly, Storage, and Games on the Web, and Ben is a software engineer on the Chrome team. Ben and Thomas join me to talk about the state of WebAssembly, what the different browser manufacturers are doing, and some cool uses for WebAssembly, from games to CDNs to cryptocurrency infrastructure.
As in the previous episodes, there was discussion of WebAssembly security and memory benefits from being a bounded context, flexible, modular place to run code. And I'm excited about WebAssembly. I can start to see so many applications for it, and there's just a lot of open questions as to how it's going to roll out and how it's going to impact people, but I plan to cover that in as much detail as possible. And you can always send me suggestions for episodes if you have seen some cool use cases or developments around WebAssembly in the wild.
I also want to mention I'm hiring for a new company that I'm starting, and I can't talk about the product quite yet, but I'm excited about it, and I'm looking for an engineer in the Bay Area who has a significant experience in React.js, and also some sort of cloud, whether that's Heroku, Firebase, Google Cloud, AWS. You can email me at Jeff at softwareengineeringdaily.com. You can check out the job posting at softwareengineeringdaily.com. And I would love to hear from you.
Ben Smith and Thomas Nautistad. Welcome to Software Engineering Daily. It's great to have you. Great to be here.
Thank you, Jeff. Today we're talking about WebAssembly. We've done a couple shows about WebAssembly recently, and on those shows people have defined WebAssembly in a number of places. It's a low-level compilation target that allows any language to run in the browser if they compile down to WebAssembly.
It's also described as a virtual machine for running WebAssembly modules, which are these sandbox execution runtimes. How do each of you describe WebAssembly? Sometimes we talk about it as being an instruction set architecture. So similar to x86 or x64 or ARM, it's a target that's like a machine.
Some people say virtual machines. Sometimes you think Java or maybe the .NET runtime. But we think of WebAssembly closer to something like what you would actually run an actual machine. Now there's a lot of differences.
But I think that's kind of like how I would think of WebAssembly. I completely agree with that assessment. And just from the perspective of a developer and how they can kind of perceive it, I think the most useful framing that I've seen developers describe is a bytecode format that I can compile something into and then kind of just ship it to have it run in the browser. Especially when you look at some of the languages that it supports right now, like C++ and Rust.
What it really does is give the developer the ability to write in those languages. And of course port existing code written in those languages as well. JavaScript is a Turing complete language. It's got a ton of community support.
In what ways is WebAssembly complementary to what we have today with JavaScript in the browser? Ben, maybe you can answer that. Yeah, so JavaScript is great, actually. It's an excellent language to use.
But there are some places where it's maybe not as appropriate. So actually what we found was there are a lot of people who want to bring applications to the web that just didn't really work in JavaScript. And so if you were compiling something like C++, two JavaScript, you can use some script to do that. You would end up with just reams and reams of JavaScript to do it.
And so as a result, you end up actually taxing the JavaScript engine a lot more than you should be. Because the JavaScript engine doesn't really expect code to be written that way. So WebAssembly actually fills that niche very, very well. And its original purpose was to provide a compilation target for low level execution that isn't written by a human.
This paradigm shift to having WebAssembly in the browser as a complement to JavaScript's execution, this requires some refactoring of the platforms that process JavaScript where we want to have WebAssembly also existing. Thomas, what adjustments do we need to make to a web browser in order to get it to execute WebAssembly? Yeah, that's a great question. Within Chrome, the WebAssembly team and the V8 slash JavaScript team are actually the exact same team.
So this is really a very joint collaboration. And the original ideas for WebAssembly actually came out of engineers on the V8 team. And so they're the ones that are the real experts on how this stuff actually works. And Ben can probably talk about the very neat and gritty details of what's changing.
But at the high level, V8 is the engine that's still doing the interpretation of the WebAssembly code as well as the JavaScript code. We just recently launched a new, what's called a baseline compiler. It's called Liffthof. And that's a compiler that is entirely responsible for just WebAssembly.
And so the V8 team had to go and write that. Yeah, I can add a little bit more to that. So the idea is basically that you already had in every high performance JavaScript engine a low level compiler that would basically take code and then compile it down to native machine code and be able to execute it very quickly. So the original sort of conception of WebAssembly was that it would actually be relatively simple for people who already have a JavaScript engine to add a WebAssembly engine because we would sort of hijack the same high performance compiler.
It turns out that we ended up needing other compilers too, such as the one that Thomas has described the baseline compiler. And that's to make it so that you can execute code very quickly, like you can compile it very quickly. But I think the original conception of integrating directly with the JavaScript compiler is still accurate. And basically all the JavaScript WebAssembly engines do that.
In talking to Steve Clabnick from Mozilla, I had him on the show yesterday. And he gave one of the earliest examples of WebAssembly being used in production. He gave the example of Dropbox. When you upload a file to Dropbox, there is some WebAssembly that runs, I suppose, on the browsers that do support WebAssembly today.
It compresses your file. So it gives you a client-side compression. I guess it's useful to have that compression algorithm written in Rust, or perhaps C++, whichever it's written in. Can you give a few other examples of where we will see WebAssembly deployed early on in the early days?
So the Dropbox case is definitely one great example of where you can take advantage of the extremely fast performance of WebAssembly to integrate into kind of an existing upper functionality. One of the things that I'm especially excited about WebAssembly enabling is, first of all, being able to port large existing applications. And the biggest example that we've seen of this so far is probably AutoCAD, which took their 35-year-old code base and compiled it to WebAssembly to enable all of their web users to access a ton of the same functionality that you previously could only get through the native app. So that's one that we've already seen.
In addition to that SketchUp, which is a 3D modeling software, did the exact same thing. They were able to port their native application to the web, which is really exciting. In addition to that, you also see some other large applications, such as Figma, which is a design tool for the web, really heavily leading into WebAssembly and use it for its highly increased performance over something like Azure. This is an illustration of two almost polar opposite types of applications, because with the case of Dropbox needing a little compression module in the browser, you have very modular component of an application.
And then in the case of something like AutoCAD, you have a giant old monolithic application that's probably written in C++ and was written in a time where people couldn't even envision the focus on Web and the emphasis on browser applications and applications that feel like their browser applications. And so you have these two almost polar opposite use cases. So can you talk about how WebAssembly is used in those two different types of use cases and why it's useful for both of those types of use cases? Yeah, absolutely.
So you're exactly right that the Dropbox use case is very modular and it's as a library. And I think this is one of the spaces that is going to grow the very most when it comes to WebAssembly and where we'll see a lot of really exciting use cases where you can take a small library that was either written already or that you've written to do some small tasks and then integrate it into your existing standard. Figma, the design company that I mentioned earlier, is an interesting illustration where they do a little bit of both. So they take some libraries and they modularly integrate that into their otherwise JS components, but then they also have large areas of their application where all of the logic is run entirely through WebAssembly.
So I see it more as a kind of gradient with two ends than kind of just two different options. It's interesting actually because with a lot of like say JavaScript frameworks versus libraries, right, this is a conversation that people have a lot. Like does the library sort of integrate nicely into your already existing application or does it sort of take over and want to control everything? And I think one of the things that's pretty exciting about WebAssembly is that it can actually fill both roles because it's so sandbox and modular, it allows you to sort of say, well, I want to have everything in this or maybe just a little piece of it.
Yeah, that's very well said Ben. And speaking of JavaScript frameworks, I'll mention that the Ember framework is currently looking at and has already started making commits to adopt a library. So that's one example of actually integrating WebAssembly into an already existing library. Okay, we've got three different case studies here.
We've got Dropbox's compression algorithm. When you upload a file, it gets compressed using some WebAssembly module or modules. We've got the example of AutoCAD, a large 35-year-old monolithic application that's probably written in C++ that was ported to WebAssembly and can now be used in the browser. And we've got the example of Ember potentially wanting to use WebAssembly for some features.
So we could run through these three as case studies in helping people understand how a module or an application gets turned into a set of WebAssembly modules or applications. So let's start with the Dropbox compression algorithm. So I assume there's somebody at Dropbox that wrote some Rust code for compressing a file, and they want to put that Rust compressor into WebAssembly so that the client on their browser can compress the file before it gets sent over the wire. You obviously want it to be in the browser, so you wouldn't want to send the file to Dropbox and have them compress it.
You would want to save on the bandwidth, so compress it beforehand. So talk about what is the compilation path. And by the way, we've done a show where we really dove in deep into this whole compilation path and the intermediate representation and LLVM stuff and so on. But maybe you could just walk through it because this Rust or this compression algorithm is a nice first example.
With Rust, it's a bit different than with C++. You would probably use in Scriptin, which is the tool chain that we usually suggest, which is essentially a wrapper. It essentially a wrapper around LLVM allows you to compile C++ and then integrates a lot of functionality that you would want if you're compiling to the Web. With Rust, it's a bit different because they control their tool chain a little bit more closely.
So what you would end up doing is using the, well, I mean, if you had Steve on yesterday, he can explain it way better than I can. But basically, you would use the Rust tool chain, pull that down, and then that would give you the tool chain to compile. And so, yeah, you would have a compression library that you would compile, and what you'd get out of the end is a WebAssembly module. What that module would do is it would have a collection of imports and a collection of exports.
And the idea is that a module by itself can't really do much of anything. And so you have to sort of tell it what, you have to sort of give it the imports to say, here's some things you can ask me, the embedder about, and then it gives you some exports saying, here's some stuff that I can do. And then when you call those exported functions, it will do what you want. So, for example, in the compression case, you would have an export function that maybe is called Compress.
And when you call that, the module might call back to you and say, well, give me some data, you know, or maybe you pass it down. There's a number of different ways you can actually configure it, but that would be basically the idea. And then you take that module and integrate it and call it through JavaScript. So there's a JavaScript API for WebAssembly modules, and you would use that to load the module into a JavaScript object and then be able to access it directly.
So the import export constraints, is that how you draw a line around, that sounds like a sandboxing limitation where it defines quite succinctly and rigidly what this module has permissions to do? Yeah, exactly. Okay. I think we could also talk about the example of the AutoCAD.
So if you had a large application that you wanted to migrate to WebAssembly in order to run it in the browser, what would that procedure look like? So it's an interesting question when you talk about a large existing application that was written without the Web in mind. And there are various things that you as an application developer do have to do in order to move that application to the Web. People always ask how magical the conversion process is to open that black box a little bit.
One of the primary things that you as an application developer have to do is figure out the parts of your application that can be modularly converted into WebAssembly and which parts won't. And some of the primary components that you won't be able to convert directly are any operating system interfaces. So if you do any Windows-based window management, then that's something that you have to rip out and replace with some new UI. But all of the kind of core components that you have, you can convert those directly into modules and then hook those modules up in whatever makes sense for your architecture.
And that's exactly what AutoCAD did. They were able to take, I think it was something like 95 or 98% of their total code base, and then they just replaced the UI components with a little bit of stuff mocked up in React and then connected the components together to get their application working. And one of the good rules of some that I've heard is that if you have a Windows-based large application and you want to bring it to the WebAssembly, it'll probably be about as much work as bringing your application to Linux. Yeah, it's very similar actually.
And I think the other thing I would add about that is that if you already have a cross platform application, something like you have a Windows version and a Mac version, then you probably already have some level of abstraction over the UI and all these sort of OS components that will be separate. And those will be the same sort of layers that you'll need to separate for bringing your application to the WebAssembly as well. Cool. Are there any gotchas that have been countered by these other people?
Because I think this is kind of procedure has been done by a number of different companies. I think Lin was also telling me that the reason team, which is like a digital audio organization, I think they've also gone through this procedure. What kind of gotchas have these large applications that have been ported to the browser? What have they encountered?
What has not worked? What's been difficult? I think the only real thing that we've heard is that some of the largest applications hit up against the 2GB memory limit, but luckily we are planning to increase that to 4. But outside of that, I don't think we've heard too many negative things.
Oh, one thing might be the state of debugging right now is definitely something that we could improve on and that we're currently working on improving. But those will be only two that come to my mind. Some of the other things are limitations in Web APIs. So because the Web doesn't allow you to access all of the functionality of your computer deliberately, right?
Because you don't want, say, a web page to start sending network packets for you, for example. There are things that are not actually, it's not able to do. And so actually one of the biggest ones is probably File System Access. For a lot of applications, that's okay because if they're running on the web, they want to have some kind of cloud storage.
But it might be very different than what you are currently implementing in your native application because people don't usually think of cloud storage there. But I think one of the things that's kind of cool about WebAssembly in that regard is that it can take a native application that maybe was limited in that way. And because it's now converted into a web application, there are certain things that you just sort of take for granted. For example, the fact that you do have a server that you can use to provide any number of pieces of functionality there, or the fact that you do get to just update your server and then provide a new application to the client directly.
So for applications today, applications like the AutoCAD for example. So this is a 3D rendering engine. And this is the type of application that people buy, that's super high-end Apple computer where it's a giant cylinder that kind of looks like a trash can. It's like $6,000.
And it's really expensive. It's really performant because you're doing some kind of 3D rendering or movie production on your laptop. And it would be great if even if you were using the WebAssembly version, you could access all of the horsepower of that computer. But my understanding is that that's probably not doable today.
And I think to your point, someday that kind of stuff will be accessible via server. Or maybe not. Or maybe you'll always need a giant trash can computer for some particular kinds of applications. Maybe it's VR or AR or something like that.
But if we assume that we do need some kind of heavy client device and we want to be able to take advantage of all of the resources on that heavy client device, Thomas, maybe you could talk about overcoming the memory constraints that exist in the browser today and kind of the memory constraint model of these WebAssembly modules. Yeah, absolutely. So I think first of all, I want to make it very clear that our goal with WebAssembly is exactly as you say to expose all of that underlying horsepower of any machine that you're on. And to make sure that any web application can take as maximum advantage of everything that your CPU slash computer has to offer.
And right now today you have a huge boon on JavaScript, but we're also adding a lot of things to let you get more control over all of the resources that your computer have. One of the big ones is Threads, of course, which gives you fast access to multiple cores on your CPU. And then additionally, also SIMB, single instruction multiple data, to really optimize for that very high mathematically intensive use cases. So like our overall ethos with WebAssembly is exactly as you describe it as getting all that horsepower.
Specific to the memory limits, we know that we can go fairly easily from the 2 gigabytes to 4 gigabytes, which should be sufficient for the vast majority of use cases. But I think there are options in the future to go even beyond that if we find that it's needed. It's just a matter of prioritizing getting the fastest bang for your buck. Sure.
Ben, anything you want to add? Yeah, so about that last point, the reason there's a 4 gigabyte limit is that currently Wasm is what we call Wasm 32, which means it's a 32-bit architecture essentially. And that actually has a lot of benefits in the sense that if you're running a 32-bit Wasm module inside a 64-bit CPU, which is what most of us have these days, you can actually use tricks to make it run fast and to perform the sandboxing that's necessary. So the option to break through that 4 gigabyte limit would be to add a Wasm 64.
We have sort of thought about that and how that might work, but we haven't actually put any serious effort into it yet. But I think it's an interesting avenue to explore in the future, definitely. Alright, the third example that you mentioned was Ember. JS.
So Ember is a web application framework for making JavaScript-based applications a higher-level JavaScript framework. How would Ember use WebAssembly? So as I understand it, Ember right now is looking at using WebAssembly to do some of the DOM diffing that they currently do for their rendering. And so that's one component of the Ember framework that is kind of bottlenecked on performance.
And so they should be able to modularly take that component out and then replace it with a WebAssembly one to just get faster improvement. That means that they'll have to figure out what language they want to use, like C++ or Rust, write the actual code in that language, and then compile it to WebAssembly and integrate it through JS API calls to their existing framework. The cool thing there though is that it means that you, as an Ember user, if you did have this, would sort of not have to even know that you were using WebAssembly. It wouldn't really even matter to you really.
You would use the same JavaScript API, or you would use the same APIs that you normally do. And it's just sort of running a WebAssembly module in the background and it just means that you're diffing as faster. And that's, of course, the beauty of a lot of this WebAssembly potential is that the power of WebAssembly will be hidden in the packages that we import. It won't be such that you need to rewrite your entire application to support WebAssembly.
It'll be that maybe you, instead of doing npm install, compression algorithm v1, you install compression algorithm v2 featuring WebAssembly, and you just get to take advantage of that. That's exactly right. And I think the two components there is one, as we already described, existing frameworks being able to swap out the parts that are performed in WebAssembly, and then also being able to swap out entire libraries. If there's a library that does something like physics or artificial intelligence or visual analysis, then you can just take those entirely, compile something down to WebAssembly and then just wrap it in a JS API.
And like you said, just swap it in. It could be the exact same APIs or previews version. But now it's just running, hopefully, several times faster. So I talked to some of the Mozilla's recently about this, who work on Rust and WebAssembly.
And they were describing this as being an interesting process where you might want to try and find where that proper dividing line is. So it might not be necessarily at the library level, but maybe it's at a little bit larger than the library level. It's not exactly clear. I think the future we want to get to is where it really could just be individual libraries.
But at least with the plans that I've heard recently, there is going to be some amount of sort of decision on the part of the application developer. But I think that actually provides you with a lot of benefits. It means that you sort of bring a bunch of these components together and then its own little component for your application that's written in WebAssembly. I'd like to revisit some of the lower level aspects of WebAssembly's runtime.
And again, we went through this in detail with Lin. But can you talk about, I'm not sure who this is a better question for, but maybe Ben, can you talk about the role of the LLVM in this process and the role of intermediate representations in making this all work in the browser? So LLVM is a suite of tools actually. It used to stand for something, but now it just stands for LLVM.
And the idea is that LLVM itself takes an intermediate representation in IR and converts it to native code. Perhaps that's x86, besides x64. And so on top of that, there's a compiler clang. And so what clang does is it converts C++ code and C code into LLVM IR, which then LLVM converts to native code.
So what we've done with WebAssembly is we have our own back end, which is basically converts from LLVM IR to WebAssembly, you could call it IR, WebAssembly by code. And so that's sort of the role of LLVM in this case, is to provide that sort of pieces that are necessary for converting from IR to WebAssembly. And the benefit there is that it means that any other front end languages can use the same back end to WebAssembly. So Rust uses the same back end to do its conversions as C++ does.
And other languages could do the same, D for example, or perhaps even languages like Go. Although with some languages, it actually ends up being a little bit more complicated. If your language maps very well to something like the same type of thing that C++ and Rust do, where it's kind of a low level systems like language, then it maps much more cleanly. If your language is more like C-sharp or Java, you might not use LLVM in that case because you have your own tool chain and you have your own sort of compiler infrastructure that you would use instead.
And so they've taken a different tack. I think I see. So LLVM is, correct if I'm wrong, is a way of writing interpreters. It's not, whereas it may have been referred to as an interpreter itself in the past.
Now it's more like you can use it to interpret things from one language into another, like a higher level language into assembly code. Yeah, I mean, usually use the term compiler, but yeah, it's the same sort of idea. It's just translating from one representation to another. And the question is whether that representation is something like a programming language or it's something like the internal representation that LLVM uses itself.
So in this case, we would take the C or C++ or Rust code. It would be compiled down to the LLVM intermediate representation. And then something would compile that intermediate representation down to the WebAssembly format? Exactly.
Yeah, that's the WebAssembly backend. So essentially, I mean, I don't know how in depth we want to get here, but there are multiple levels of, well, there's just one IR, but there's actually different formats that it takes sort of as it goes through the process. But the whole idea is that you can sort of write the IR in, say, more of a normal way, more like a programmer would do. And then the whole point of the sort of LLVM infrastructure is that it can take that format and then it can do optimizations on it and prove the code and produce better output than you would be able to.
You could do it by hand, but you wouldn't want to is sort of the question. So that's kind of what LLVM is doing for you there. It's providing that level of optimization over the code that you write. So in managed runtimes, I think you have this hot code path runtime situation where your virtual machine can look at the code that's executing and it can look at, for example, the code that's executing in loops.
And since it's executing in loops, it can optimize that code to run faster. But I think in these modules, that's not exactly what we want, because we have a sandboxed amount of memory. Is there some degree of management that's occurring over these modules once they are fully compiled into the WebAssembly format? Is there a management layer that's doing things like hot code path detection?
You could do that, but WebAssembly is actually specifically designed so that you don't have to do that. So one of the things that makes writing a JavaScript VM so difficult, it's like you say, it is a dynamic language. And so you have to, if you converted JavaScript directly into machine code, and there actually are JavaScript engines that do this, it wouldn't run as fast as a lot of the engines that we have today. The reason that runs fast is that it does exactly what you're saying.
It sort of analyzes the code as it's running, tries to determine the things that are currently the slowest or the things that are the hottest, and then it tries to optimize that. But what WebAssembly has is it has all information about the types of the system and all the layouts and all the structures, and so like C++, or very similar to C++, it can actually do much more ahead of time compilation. So what happens is when you write your code in C++ and you compile it to WebAssembly, it actually will do a lot of the same optimizations that your C++ code would do when it's compiling to X64 or to ARM. The difference is that there's a separate compilation process that happens when you take WebAssembly and you convert it to the actual native code, and that happens on the client side in the browser.
And so the WebAssembly engine itself can sort of choose what it wants to do. It could just take a WebAssembly code and convert it to assembly code directly, and since it's already been optimized by something like LVM, that's maybe not such a bad choice, actually. But you can also choose to take that WebAssembly code and then perform more optimizations still on it. And there might still be optimizations you can do because, let's say, the generated WebAssembly, there was already some optimizations done, but there are certain optimizations you could only do once you have a native architect.
So that's kind of what is happening. There's actually two compilation steps that happen and two potential points for optimization as well. In terms of the security and the sandboxing of WebAssembly, can you talk about, maybe Thomas can talk to this as well, the standards that you need to impose around whatever that sandbox is and developing that API for the modules to make sure that they have enough privileges, but they are also highly constrained because the WebAssembly is such an insecure place to play in. Yeah, I can speak to this.
So when I think about security and API access of WebAssembly, there's two components. First of all, the computational sandboxing, which makes sure that you can't access any part of the stack that you aren't supposed to. And WebAssembly has very strong boundaries there. We do what's called bounds checking on every operation so that you can't snoop on any parts of the application that your WebAssembly code isn't supposed to be snooping on.
In addition to that, there's something very separate, which is what APIs that they have access to. These can be things like WebGL or other APIs, and all of that is currently mediated through JavaScript. So WebAssembly, as I think we mentioned earlier, doesn't get access to anything today that JavaScript doesn't have access to, except faster compilation. And so right now WebAssembly fucks out to JavaScript when it wants to make a Web API call, and then you can turn back into the WebAssembly with the result, and in the future we're hoping to be able to cut out the JavaScript middleman through something called host bindings.
But even then, you will still only have access to all the things that you still have access to through JS. So in that sense, WebAssembly in no way breaks any of the existing security model around the Web. And then maybe you can speak to a little bit of some of the like, module import exporters. There's not much to say there except for that you really can only import and export functions and globals.
And well, actually, you can import WebAssembly memories and WebAssembly tables as well, but sort of functions and globals are sort of the most natural thing to think about. And the idea there is just that like, you can take a JavaScript function and you can pass it as an import to WebAssembly module. And then whenever the WebAssembly module wants to call, it'll just call out through that function. And then there's a translation layer that basically pops that over back to JavaScript.
So that's sort of the way that you interact. And these different modules, the different WebAssembly modules, I want to understand a little bit better how they're interacting with each other and also how they are getting created and destroyed, are the different WebAssembly modules sharing memory with each other? Or are they copying values and passing them to each other? And are these different modules being managed by some overseer in the browser that can know about the different modules that you're running?
Tell me a little bit more about that overview of the different modules. Yeah, I'll talk about this a little bit. So there is no really overseer. I mean, you might say that the browser engine itself sort of knows about all the different WebAssembly modules and knows perhaps how they want to be interacting.
So if you did have two WebAssembly modules that one exported a function and the other imported that function, the browser engine knows that it can call straight through from one function to another. But in general, it's sort of the responsibility of the JavaScript application to provide that sort of glue. Now that's currently the case. What we're trying to work on is better ES6 module integration.
There's a proposal for that. And the idea there is that then you could actually have something like ES6 module, which is actually a WebAssembly module. And those, you know, they both use the term module and so you'd think that they're similar and they are similar in some ways, but there are some differences as well. But then the goal there would be that you would actually have a module that you can import just like you would import a JavaScript module and it might be more transparent.
As it is currently, the way that data is shared between modules and even between a WebAssembly module and JavaScript is through what we call WebAssembly memory, which is, we also call linear memory. The idea is that it's just a linear collection of bytes. So you might almost think of it as being the same way that you take some data and you serialize it to a file when you're writing out your file system state. It's very similar.
You would have to have a format that you write out that both sides know about. So the WebAssembly module writes out to the memory and says, here's my data. And then the JavaScript site says, oh, I know how to read that data. And there are tools that actually make the simple so you don't have to do it yourself, but that's basically the idea.
Okay, let's zoom out a little bit. I think we've given people enough of the low-level guts of WebAssembly for now. The use cases for WebAssembly outside of the browser. It's easy for people to understand how this is useful inside the browser, but I think the vision for WebAssembly is much bigger.
I think the vision is that WebAssembly is going to be permeating your whole experience as a computer user. Your experience navigating your file system, for example, will feel a little bit more interconnected with the Web itself instead of feeling like this very just clients. And like this very just client-sidey thing. Am I understanding that correctly?
Can you tell me more about what is going to be the sensation of the computer user when WebAssembly is permeating more of our application surface area? So when we think about WebAssembly and non-web contexts, we oftentimes have seen interesting use cases on the server and through blockchain. So one of the interesting things that have been done on the server are things like CDNs like CloudFlare, that started adopting WebAssembly, and they've adopted it because they're interested in its security properties, meaning that they can let users write WebAssembly or a language that compiles to WebAssembly and then have guarantees that they can run that securely and sandboxed on their server to do conditional CDN posting, for example. The second example is blockchain, which again values it for that same kind of security property.
An interesting exhibit is that in the last several months we've lost two of the main team members on WebAssembly, two blockchains startups. So certainly there are people out there who are excited about this use case for WebAssembly as are we. And in terms of having it run on client machines, I don't think that's a use case that we've really seen so far. It's not like you get any additional ability to interface with the browser by running WebAssembly inside of, say, a native application anymore so than you could with any other language.
I'll add a little bit to that actually. WebAssembly has a lot of really interesting properties that make it very attractive to people. It actually sort of fills a sweet spot that hasn't really been covered by any other format as far as I can tell. And so a couple of those things are it's very, very highly specified.
And so, and it's almost completely deterministic. There are a few corner cases that are non-deterministic. So that's actually one of the biggest things for blockchain people is that they need a very deterministic runtime. And they had their own VM, but it was very convenient to reuse the WebAssembly VM because we were already doing a lot of the work on the tool chain support and it's a format that's specified.
So that's one of the other really big things for them is just that they can say, oh, this already exists and we can just use it. So they're very, very excited about that. Another thing that's really great about WebAssembly is that it's a low level. And so it's a little less opinionated than other formats.
So in the past you'd have a format like, say Java.net, which provides a lot of the same sort of ideas, but it's more opinionated and that it has its own object model. And currently WebAssembly doesn't have that. And so what that means is that you can sort of use it for more things than you might use Java for. So in the case of like taking C++ code, you could compile that to Java module, but people mostly don't because it's not a great match.
Whereas WebAssembly was specifically designed for that. So another thing that's really pretty valuable about WebAssembly is that it's a portable executable format. So in the same way as Java.net, you can use it as sort of a way to say, well, write some code and hand it off to somebody. And it can run on any architecture.
So it actually gives people who are writing an OS or some kind of platform a lot of power because it means that they can say, well, right now our platform only runs on say MIPS, but if we wanted to run on X64, we don't actually have to change anything because we already have this portable executable format. So we actually have started to see people using it for that purpose, using it as sort of a format that you can just sort of hand off and just assume that it'll work and it'll run fast too. As a sandbox, why is WebAssembly preferable to Docker, for example? Docker is actually really, really cool.
Obviously it allows you to take something like an application that's written for Linux and provide sort of all the infrastructure around it that's necessary so that you don't really have to know what the application needs. And so in a way, you might say that it's very similar to WebAssembly. The biggest difference is that WebAssembly is much, much, much lower level than that. I guess sort of it's sandboxes is more on the level of a process sandbox, whereas Docker is more on the level of being like an operating system sandbox.
So one of the big benefits there is you can take a WebAssembly module and you can run, I mean, you can run 10,000 of them probably and I think that would be fine. I think you maybe do the same with Docker. I don't really know enough about the specifics there, but you might end up being hitting limits, whereas we already see people run WebAssembly modules. Like you could run multiple WebAssembly modules in one process and because you have the sandbox, you don't really have to worry about cross talk as long as you sort of, there's mutual trust between those in the process.
So there's a lot of benefits there. That is cool. And I need to do blockchain WebAssembly show. Although I hesitate to say that because whenever I do like, hey, email me with your blockchain related ideas, I get a bunch of crazy ICO companies, but I'm sure there's some legit ones that would be more than welcome to talk about WebAssembly.
So in terms of developments at Google, Ben, you're on the Chrome team. What does that integration from the point of view of a browser manufacturer? And then, Thomas, I know you can talk to this on a diplomatic level and at an industry wide level as well. Ben, maybe you could give me your perspective on how support for WebAssembly is being integrated into Chrome and your outlook for how it will develop in the future.
Yeah, I can talk a little bit about this, although I think Thomas actually is a bit better person. Mostly the idea is that, I mean, WebAssembly is really exciting for a lot of people inside of the Chrome team. I think one of the things that's very cool about it is that it sort of opens the door to a lot of new applications like we were discussing before. And so I guess the question was mostly about sort of integration and how we think about it inside Google.
I would say, I don't know, maybe Thomas can feel this better actually. If there's interest in kind of peaking behind the curtain of how these teams are organized, I'm more than happy to give that kind of detail. Yeah, do it. Yeah, so I'm the product manager of the V18, which also consists of the WebAssembly team.
And Ben is one of the co-chairs of the community group for the WebAssembly CG group, which is the browser group. Within Chrome, you have the full list of everybody who's working on Chrome. And then within that, you have what's called the web platform, which is the team that's responsible for all of the exciting underlying technologies like JavaScript, CSS, web APIs, etc. And within that, you have the V18, which is led by someone named Dana, who's fantastic.
And within the V18, you have the team that's responsible for some of the tooling. You have a small team that's responsible for integration with Node.js, which we've been investing in a lot more recently. And then you have WebAssembly, which is a sizable portion of the overall V18, and that's the team that Ben sits on. And tell me more about the cross-browser cross-company discussions and how consensus is reached on stuff.
Do different companies focus on different aspects of this? Just tell me more about the diplomacy. Yeah, I can talk about this a little bit. So we actually are a W3 group.
We have a working group and a community group. And the differences there are mostly technical, so I won't go into too much. But the basic idea is that we have a community group, which anybody can join, and I encourage people to join if they're interested in WebAssembly. And the idea is that that's sort of where we do our technical steering.
So currently it has a lot of people from the web browsers, so we have representatives from Google and Mozilla and representatives working on JavaScript Core, which is the WebKit toolkit, and also Microsoft, and many others, blockchain people. And the way the process works is that you basically, well, we use GitHub issues, and we use, and so you basically file a ticket and you add a little item to the agenda. And we meet every two weeks, and we discuss basically interesting topics, things that we want to do to try and move WebAssembly forward and just make it better. So the consensus process is usually just that we discuss a topic and then we have a vote, strongly favor, in favor, neutral, opposed, and strongly opposed.
And we use that to help sort of drive the direction. And then when the community group is done with that, then sort of has an idea about a technical idea. Then we move that over to the working group and then we try and standardize it. I'd like to have a little bit of speculation on this show because WebAssembly is something that's fun to speculate about, because it's almost like the blockchain stuff as well.
You know it's going to impact our world, but it's not quite clear how and to what degree it will. Maybe we could take an application, we don't have to take it. So I was thinking something like Gmail or Google Docs or Hangouts. I can imagine all of these Google applications that I access in the browser and all of these ways that they could be improved by WebAssembly.
We could even take Zencaster, the application that we're using to record the podcast right now. It's a streaming audio application, it's recording our audio. What are some of the different ways that WebAssembly could improve the performance of our different highly resource intensive Web applications? I think for all of these applications it really comes down to their specific architecture and where their bottlenecks lie.
So Zencaster, for those of you listening, is an amazing piece of software. I've been really enjoying using it because you can kind of just share out a link and then I can join the application and jump right into the action. But of course recording audio, especially multiple streams, can oftentimes be bottleneck. And so our hope is that WebAssembly, for example, just a tech Zencaster could integrate with maybe encoding the audio, uploading or minimizing the audio files that they could be a better uploaded faster and have less pauses and jink in it.
But I unfortunately don't know enough about the architecture of Zencaster to say exactly where the bottlenecks lie. But certainly we've had some explorations with internal Google teams such as the Photos team about spaces and points in their application where they see jink and where they see a degrading experience. And WebAssembly could very potentially help decrease those. Yeah, I agree.
And I think one of the things we're sort of seeing now is that there are a lot of applications that are maybe not so interested in WebAssembly because it just doesn't really fit into their workflow. It really is currently very much more useful for people who have C++ or Rust or code like that, you know, sort of low-level systems codes, which means that it works great for things like if you already have a code base in that form or if you're doing something that's highly performant like compression or something. But we are planning and proposing many new features that will make it useful for people who are just doing everyday average coding and providing features for languages that do that sort of thing as well. And so I think that will sort of be the big turning point.
And I think that's one of the things I'm most excited about in the next year, two, three, four years or something, which will be when we sort of open the gates to all new sorts of languages that can be compiled to WebAssembly and then integrated into the Web. I think that will be very, very exciting. I think you'll see a lot of people start to just jump on it and use it for any number of things, like things we can't even imagine right now. I think that's very, very exciting.
Yeah. Why has it go been more widely used for WebAssembly modules? Why has the focus just been on Rust and C++ and C? This essentially comes down to whether or not the language is a managed language, which means does the language have its own internal garbage collection system or does it rely on manually managing the memory?
And something like C++ and actually Rust as well does have that manual memory allocation, and that means that when you write Rust code, we can translate that very directly into WebAssembly without having any concerns around memory leaking. The issue comes in when you have an internalized garbage collection system that you then have to compile. You can end up having some weird cycles with the actual web browser that can cause some of these applications to potentially leak memory unless you're extremely careful. So it can be done in some cases, but it's something you have to be very careful about.
We're working on a proposal called the Managed Objects Proposal as part of the WebAssembly CG group, and what hopefully that will enable is better integration of external languages their garbage collection system with a garbage collection system built into WebAssembly so that they can better manage their memory and prevent memory leaks. I didn't know Go was a garbage collected language. Yep, it is. And actually there is a version of Go that you can compile the WebAssembly currently.
I think it's maybe sort of just more experimental at this point, but our goal is definitely to make it so that languages like Go can use WebAssembly and people can just not really have to think about it. But yeah, I think WebAssembly as it currently exists is going to be a little bit of a rough place for them for that, but we're definitely moving in a direction where we can make it easier for them. JavaScript is necessary in this interaction between web applications and WebAssembly modules. As WebAssembly becomes more important, how do you think it will change JavaScript?
I always expect JavaScript to exist in the browser, and I don't expect that people, at least in my foreseeable future of what I can imagine, I don't imagine that people will drop having to write some amount of JavaScript. My hope is that for those who really don't want to, they can write extremely minimal JavaScript, but WebAssembly as a goal is in no way trying to replace JavaScript, so I think that they will continue to interoperate. JavaScript, because it was the only language of the Web for what 20 years or something, ended up having to sort of put on a lot of different hats. And so because it's a language that people write by hand, it has to have a lot of features that make it nice to write by hand, you know, and so a lot of the features that the technical group adds are features that make it nice to write by hand, you know, and so a lot of the features that the technical group adds are features that are useful, but they are mostly useful for people.
And so in some ways, I think WebAssembly takes a lot of pressure off of JavaScript as a language. You can push it in more of a direction to make it useful for people, and you don't have to worry about making it a language that's useful as a compilation target for programs. The hope I have is that when people think, well, I want a new language to run on the Web, they think, oh, I can use WebAssembly, and they don't have to use JavaScript. And I think for JavaScript, that'll be great.
That means that they can focus on making it a language that they want, that language that people want, as opposed to language that people are sort of cramming their ideas into, you know. Okay, well, let's wrap up with just a little bit of forecasting. So in about a year, where do you each of you think WebAssembly will be? What kinds of progress will have been made and what we'll be doing with WebAssembly?
So I'll speak maybe to my hopes about the ecosystem and then can speak a little bit more to the format, but I think WebAssembly is going to really continue to take off in the next year. I think we're going to see a large number of large applications similar to the AutoCAD Sketchup and Figment of the world start to come to the web and especially existing native applications. I'm also extremely excited about what the kind of grassroots developer community will do with libraries and what kind of libraries you will see. I think you'll start to see WebAssembly integrated both as kind of libraries by their own right and also integrated into existing libraries and frameworks, such as the example with EmberShow.
And on the note of libraries, I'm especially excited about what people will do with the existing Wealth of C++ libraries. You can take things like that were part of Knew or other like amazing open source C++ projects and libraries and you can just now get to utilize those in the browser. And if you're an extremely awesome and kind developer, you'll wrap that library in the JS API, upload its MPM and now suddenly the entire developer ecosystem has access to that new library and functionality with a minimal amount of work on any given one developer. So that's where I see WebAssembly going.
Yeah, so I'm excited about all that stuff too. I think I focus much more on the technical side of things. And so one of the things I'm most excited about and I think we'll definitely see in a year is threads and probably SIMD as well. And that just means it'll be much more possible for like we were talking about earlier for you to basically use all the functionality that your machine expects.
So you could basically load up an application in the web and you could run it and not even have to think about it. You could basically have applications that are as powerful as things like Photoshop running in the web. I think that's pretty reasonable to assume. One thing we actually haven't talked about at all in this podcast, which is really surprising is we'll probably see a bunch of games too.
We've been talking to a ton of people who are interested in games and bringing their games to the web. And I think we'll see a lot of that. Very, very excited about that. You're exactly right.
And it's surprising we haven't mentioned that. Just to maybe end to the podcast on that note, we have been working really closely with Unity and Unreal Game Engines and they both now support and export target. That is the web so that you can take any of your existing Unity or Unreal content and then just compile it to WebAssembly and ship it in the browser and take advantage of all the advances in WebGL technologies to run an extremely performant game experience. And then leverage all of the things that make the web awesome like the fact that I can start a game, copy the URL, send it to my friend and he can just click it and instantly be in the action without having to worry about downloading or doing any of that kind of up front later.
And I'm really excited to see what kind of games will be enabled by that. Very cool. Well, you guys are giving me a lot of ideas for future shows. I think I can basically, I can almost envision a series of shows on WebAssembly in practice with some of these different verticals.
So, Ben and Thomas, thank you for both coming on the show. I've really enjoyed this conversation. Thanks for having us. Yeah, thanks so much.