 Hi, everyone. I'm here to talk to you about WebAssembly, like, as AmeriCode kindly said, I did race a car across the desert. I also flew on the Concorde on frequent fly points. So I've had this obsession with speed, and which is why I love WebAssembly. It's fantastic. And what you need to understand is what it actually is, right? It's a new capability for the web. It's a way that you can build really high-performance code and have it run inside your web application. It's also not a replacement for JavaScript. It works alongside JavaScript. So what it enables you to do is to take things like C++ and Rust and compile it into what we call a WebAssembly module or Wazm module. And you can load that into your web application and call it from JavaScript. Now, when we were developing this, one of the things was speed, right? It runs extremely fast. It runs at a small percentage slower than true native code. But more importantly, it's very secure. So what Wazm is, it's kind of a binary format that was specifically designed to be safer than JavaScript. So the instructions are very restricted. It's proven like there's a mathematical proof in a published paper about it. So it actually adds... There's a whole security layer by design. And on top of that, it runs inside Chrome Sandbox. So there are a couple of layers of protection there for you when you use it. But probably a bigger goal was portability. So we wanted to enable the compile once-run-everywhere model. And so it actually does run across a whole lot of browsers. So you might be wondering, what can you actually do with it? Well, say you already have a whole lot of native code. You might have a native app that runs on desktop or even in an app store. And it could be written in C++. It could contain business logic. Or you could have a game engine that's also like many, many man years of invested time. So you could have a multi-million line code base sitting out there in your native application. Now, you might think about bringing that over into the web. Now, during the keynote yesterday, there was this whole talk of the new web capabilities. If you have a native app, you can now pull in the web browser without the URL bar at the top, which was making the native app kind of or the web more native-like. Well, WebAssembly is the opposite end. It's making your web app more native-like. It actually pulls in these native things. So picture this. Picture a new video format. So we all use various video formats. There's WebM, there's H264, there's a whole lot of different video formats. But if you were, say, a developer that decided to come up with a whole new codec or a still-image codec, you might want to deploy that across the web. Now, you could do two things. You could wait for the browser implementers to actually implement it. You could log a bug against all the browser saying, implement my new cool image format or my new video format. Or you could just compile your C++ code into a WebAssembly module, load it in your web app, and use that video format everywhere without any changes. Hi, I'm Deepti. I'm a software engineer on the WebAssembly team. So you've heard Alex talk about what WebAssembly is. Why should you care? Why is this relevant to you today? So more and more applications are moving to the web. You have audio decoders, video decoders, game engines, music applications, and a whole lot of other computation-intensive applications. And we want these to run at near-native speeds and not need to be recompiled for each platform. And that's exactly what Wasm gives you. So, and that's exactly what Wasm gives you. And we have Chrome, Firefox, Safari, Edge, all support the first version of WebAssembly. And Edge, in fact, just shipped last week. And we're very excited about that. So what are some of the big companies that are using WebAssembly right now? This is a gif of the Unity game tanks. We have a screenshot from the Epic Zen garden from the Unreal Engine. And so we want to dig a little deeper into why all of these companies use Wasm. When you have a Wasm module, all of the module information is encoded in a dense binary format. So what this means is you have smaller binary sizes. You have faster loading, faster decoding. It's a smaller memory footprint. And it's just fewer bits over the wire, so everything is faster. So one of the things we want to do with this presentation is to showcase all of the variety of applications and use cases that Wasm works really well for. So Website is a demo, is a real-time face detection demo, is a real-time performance demo of a face detection algorithm that uses OpenCV. For those of you that are not familiar with OpenCV, OpenCV is the open source computer vision library. And it's extensively used. So let's switch to the demo, please. So as you can see here, what we have is you have the WebAssembly version, which is OpenCV that's compiled to Wasm, running on the left side. And on the right side, you have handwritten JavaScript. The performance is measured by the amount of time it takes to detect Alex's face in the video stream. So as you can see, the Wasm version is currently at about 16 to 18 frames per second. And the JavaScript version is at about 2, 3 frames per second. What we want to show you here is that the Wasm version is so much faster than the JavaScript version. Can we switch to the slides, please? So like I said, this is an example of a large existing CC++ code base that was compiled to Wasm and ported to run in the web. And you can see that these are significant performance gains. The thing to bear in mind here is that the handwritten JavaScript might not actually be the fastest JavaScript there is. So the performance here might be slightly inflated. But you can still see that the performance difference is actually quite large. If you want to check out what is actually available, that's website, S-I-G-H-T. So make sure you look for the right thing. So when we were getting this talk ready, I was trying to think of what we could show you to give you an idea of what you could use WebAssembly for. So it's like we all build websites, right? And so these days, your average website is probably a megabyte or so. And 80% of that would likely be images. So I don't know about you, but my workflow is typically I'll take photos with my camera or whatever, and then I'll pull it into Photoshop, and I'll crop and tweak, and then I'll adjust the quality to try and get that image small. Because we want to save bytes on the wire, we want to make our pages smaller, and part of that is optimizing your images. I don't know, other people use command line tools, you use your favorite things. So I thought, what if we could actually do that inside the browser? So what I did was I took the independent JPEG group codec. So this is code that is in a lot of production applications. It's probably 20 years old by now. So it's had many, many years of debugging. It's rock solid. It ships in production. In fact, a derivative of it is inside blink to decode JPEG images, but we don't have a JPEG encoder in blink, right? So what I thought is, why don't I just take the IJG code, compile it into like a module, I can then load that module into my page, and I can load images and start playing with the quality and size to see what happens. So step one, which I encourage you all to do is to download the M-script and SDK and install it on your workstation. So once you've installed it, you will have a bunch of command line tools that help you work with WebAssembly. So this is what I do to compile my little JPEG transcoder. It's nice and simple. So EMCC is the M-script and C compiler. Now this flag minus swasm equals one tells the compiler to generate a WebAssembly module for me. The next line, which says minus export functions is JPEG transcode, exposes the C function JPEG underscore transcode to JavaScript courtesy of WebAssembly. So you can actually put a list of functions in here and export all of them. The next line, the output is JPEG squash.js. So what that is, is M-script and generated glue code. So that is JavaScript code that manages the WebAssembly module for you. So it manages the interface, it manages the loading, it manages all the calls in and out, et cetera. And then of course, the last thing is my source file at jpegtranscode.c. So once you've done that on your command line, it will build you a JavaScript thing called jpegsquash.js and a WebAssembly module. And this is how you use it from your HTML. So the first thing you do is put in this script tag, which pulls in jpegsquash.js. Now what this does is pulls in the WebAssembly module, hooks up all the glue logic and creates a global object called module. And module is how you interface to your WebAssembly. So the code that I actually write myself or you write as a developer is something like this. The first thing I do is set a boolean saying the WebAssembly is not loaded. Now the reason I do this is because WebAssembly modules are loaded asynchronously. So what happens is that when the first script line is executed, it kicks off the load and then it kicks off the actual compile. So in the background, the browser is compiling the WebAssembly module to machine code while the rest of your page is continuing to load. So they're running in parallel. Now in a future version of Chrome, we're gonna change this and we're actually gonna have streaming compile. So as the WASM module is coming across the wire, it will be compiling at the same time, which will give you faster startup. So I set this property on the module object, which is on runtime initialized. I set that to a function and that function will be loaded when my WebAssembly is ready. So it just sets the boolean to say, I can use this stuff. And so this is the simple function I wrote to bash JPEGs. So it takes two arguments. The source is a typed array containing my original compressed JPEG image. The second argument is the quality I'd like to compress that down to. So if the WebAssembly is not loaded, I just do nothing. If it's loaded, I call this function JPEG transcode, which if you recall on the previous slide, I had in my exports. So this passes in the source typed array, the number of bytes that it is and the quality I wanna set it to. And under the covers, it goes off to the C code that's been compiled. It decompresses the JPEG image. It recompresses it at the new quality and returns it inside that source typed array. And the return value from that function is the number of bytes of the newly compressed data. Now, of course, I can't put a typed array on my page very easily. So what I need to do is convert it to a blob URL. So we pass in that typed array into this function, make blob URL, which creates a blob URL, tags it with the MIME type image JPEG, and then I can attach it to any image node or even put it as a CSS background image. So why don't we just go to the demo and I'll show you how this works. Okay, so here's my beautiful UI of the application that I've built. And of course, it's the WebAssembly logo there. So I could pick a file. So say I've taken a photo on my camera, I can just click the choose file dialogue, which of course is being nice and slow on me. There we go. So I'll just pick this photo of my daughter and here I'm recompressing it at quality five. So you can see the original image on the left. You can see if you compress it to Q5 on the right. Now if I just grab the slider and bump it up to full quality, I'll kind of explain why I'm doing this. So this is 100% quality. The image is absolutely identical, but it's 935 kilobytes. Remember when I mentioned a megabyte for the typical web page? I don't want to deliver a megabyte. So I could like play binary chop or something. Well, let's go somewhere around the middle. So at 45, it's gone from 900K to 100K, and still this image is still not too bad. Like you can, you almost can't really tell. In fact, I can't really see a lot of difference here. I don't know about you. So let's go smaller again. So quality of 23. Now it's probably not so clear on the projector. You can actually see it. There are a few bands in the sky there, but overall the face is still kind of recognizable. The parrots are happy. You know, I might just ship this because the subject is clear, the sky's a bit bad, but I've only got 68 kilobytes. Now, the reason I'm doing this in the browser myself because I want to actually hand-optimize it using my eyes to decide what it's going to do. Because if you use an automatic JPEG compression tool, it will use things like signal to noise ratio and decide to deliver you an image that is imperceptible from the original. And that's not what I want. I want to deliver less bytes over the wire. So I'll just show you one more image quickly. So this is an image that I took on Sunday with my Pixel 2. So this is a butterfly at the Californian Academy of Sciences. And again, I've compressed this at 23 quality, which is what I was using for the previous photo. It's only 54K. But you'll notice in this particular image only the center matters. Like there's this butterfly, it's in focus. And over the side here, it's all blurry because there's a lot of depth of field happening. So in fact, I could even shrink this even more. So we have 50K now. And I've experimented with this before I went on stage. So if you bump it down to, like, say, 10, that's still relatively clear in the middle. And you'll notice the background here. Like, you see the blur on the left and the blockiness on the right. Well, I don't care about that blockiness. So I can use my better judgment to say, well, that's blurred anyway, I'll let it be blocky. And in fact, this kind of gives it this artistic look. And then I only ship 37 kilobytes to my users. OK, so we flip back to the slides, please. By the way, if you want me to open source that, just ping me on Twitter. And I'll happily publish it. OK, so that's what one person would do as a bit of fun. Something that I would do in my day-to-day web workflow. But now I wanted to show you something that's a bit more serious. This is like a serious engineering company building a large-ish product. So what I'm going to talk about is this thing called Construct 3. And what this is, it's an in-browser game editor. So it's like a full-blown IDE, but running inside the browser courtesy of WebAssembly. Now, what they've done here is they've wrapped a whole lot of public open source libraries into an application that combines the best of native and the best of web. And this is what I was talking about earlier. Like, the keynote may improve native apps with web. But we're actually improving web apps with native. So what they bring into their application, they bring in a bunch of open source libraries, like they use FFmpeg for video encoding and decoding. They use Box2D as a physics engine. They use Zlib for compression. They use PNG Crush to squash down their PNG images. But they're not just using native code. They're also using a lot of browser capabilities. So they're using HTTP2. They're using ServiceWorker. They're using WebGL2, and they fall back to WebGL1 if it's not available. They use WebAudio for all their sound. They even use WebRTC. And so this is a full-featured, rich app. And one thing that's really, really interesting about their web experience is that the size of the thing they load is smaller than their native app. Now, you think about that for a minute. Because when they ship their native app, they have to compile all those native libraries, such as FFmpeg, et cetera, et cetera. But then they need to use the functionality that's already built in the browser. So things like WebRTC, like compiling that alone is like 2 and 1 half meg. So that has to be put into the native app. But when it's on the web, they can actually load a smaller payload, and it actually loads a lot quicker than their native app. So can we switch back to the demo, please? I'll just show you what this thing does. OK, so here is their IDE running inside the browser. Like, if there wasn't a URL bar there, you'd probably think this is like Xcode or Visual Studio or something like that. It's a full-featured web-based game editor. So it has things like the start page. We have tree controls here, and you have proper tree controls that work. We have property pages. We have this property page here somewhere. So like property pages, we even have a preview of the game that you're working on. Like, there in the window, you have inspectors on the left. So at the moment here, it says press to begin. I could just go over here to the tree control and click on the text that's displaying there. And if I scroll down in this inspector, I've clicked multiple things over here. I'll begin text. Then we can actually see, here's the text for press to begin. I can just change that to hello. And it changes in my preview window. Or I can even go into the editor, like in my kind of whizzy wig mode, and pull up the dialog box and change it to something, whoop, can't even spell. And then we actually change this live in our preview. So this is actually doing a lot of work in WebAssembly and taking advantage of the power of the browser. So the people that built Construct 3 also have all these great things, like you can actually start playing your game. So you can come up with a mouse. Here we go, hit play. Prepairs preparing the images, packing the game. And it pulls up a new window running this thing. So I can actually start playing this game. So I can fly around and start shooting things. And as you can see, it's nice and performant, because a lot of the logic is actually in native code running through WebAssembly module, which is very, very nice. Now, one of the things that they've built with this IDE is they've got all the native code that does all the magic and the editing and the tree controls at Teftra. But they've also used some of the best parts of the web. Now, what they've built is they've built this thing called Remote Preview. And what Remote Preview does is it creates this QR code. Like, I'm just going to pull out my phone and scan this QR code quickly, which gives me a URL, which I can click on. If I click on that URL, you'll see it's connected to this client, Chrome 62 on Android, right? And what it's actually doing is it creates... Excellent. I was actually going to ask you all to do that. All right, everybody, get your phones out and scan this QR code. I'll leave that there for a while. Many of you would want to do this, as you can. See if we can crash the server. I think if we try hard enough, we can. Keep going. So what this does is it actually takes advantage of WebRTC. I'm going to keep scrolling it. So WebRTC has this thing called a data channel. And that lets you send arbitrary binary data around. And so, in fact... I'll just leave that. How many have we got? 33? Do you want to keep scrolling? LAUGHTER And you've slowed down my load. I'm only at 97.9% here, people. Come on. And I'm loading the images. Anyway, it allows you to send binary data around the place. So they're in their IDE. They've actually built WebRTC data channel to talk to your mobile device and then send the WebAssembly modules across and all the images and the entire game. And then you can start playing the game in your phone straight from your IDE and try it out. So it's a very powerful facility, and hopefully some of you will get it loaded in a minute and can play. Can we go back to the slides, please? So we've heard about projects that are successfully using Wasm right now. We've heard about a whole bunch of these demos, and I want to talk about some really exciting things that we're working on for the future. So first up, we have threads. So the Threads proposal provides low-level building blocks for pre-thread-style shared memory between threads or web workers in this case and concurrency using atomics in few texas. So a lot of the existing native libraries that are available extensively use threads. So adding threads to Wasm simplifies porting multi-threaded applications to the web. And as a developer, this is functionality that you can use in your applications. You can build multi-threaded applications and have them work faster. And what's really exciting about this is that this is coming soon. We're actively working on it, and we should have something for you to try by the end of the year and launch in the first half of next year. So because of the nature of compilation targets, debugging in Wasm is not always easy. We have support for basic debugging, but we're actively working on adding source maps, memory inspection and all of that good stuff, so it will make debugging your application simpler and help with figuring out exactly what's going on with your application. What are some of the other features that we're working on? We're working on adding SIMD support. What does this mean? That means that we're adding support for vector instructions that are used in image, video processing, cryptography, et cetera. We are also working on zero-cost exception handling. So when you have CC++ applications that extensively use exceptions, what happens is that right now, we're emulating these using JavaScript, but that's not really fast, so we want to be able to provide a way for these to work in a way that there's no overhead. So a lot of this presentation, we've been talking about CC++ libraries, but what about support for other languages? To do that, we need garbage collection. We need to be able to efficiently allocate and manipulate managed objects directly from Wasm code, and there's a proposal in progress for adding GC support to Wasm. So so far, you've seen a variety of applications. You've seen game engines. You've seen image detection, compression, modular libraries. But how big can this really get? How about the size of the Earth? Let's switch to the demo, please. Thank you. So you've seen a snippet of this in... You've seen a snippet of this in the keynote yesterday, but we want to show you what a complex application like Google Earth looks like in practice when it's using Wasm. Let's go to the Empire State Building. You can see that this is a whole immersive application. You've got some awesome 3D content. You've got knowledge cards that tell you what other interesting sites are around. So let's try Voyager. Voyager is this really interesting application that lets you explore different destinations from around the world, and I love travelling, so let's see what interesting things we have here. So unusual city streets. How about that? So these are curated map stories that are available, so let's go. So let's see if this actually brings up Street View. And what I want to point out here is that this is using shaders, WebGL APIs, you know, and seamlessly interfacing in and out of the Wasm runtime to do this incredible immersive experience. One of the criticisms about Google Earth when it first came out was that it was Chrome only. Now, let's pull this up in Firefox and see what happens. We'll give it a second to load, but what we expect to see here is that this works just as well in Firefox as well as it does in Chrome. So to do an apples-to-apples comparison, let's look for the Empire State Building again. So you've got like a very similar, you know, the same 3D content, everything that's available in Chrome that's also available in Firefox. So you can see that this works in a truly portable way. Let's switch back to Slice, please. I also want to give a shout out to our colleagues on the Earth team that have worked on porting this to Wasm and made this such a seamless experience. They're here, Jordan and his team are here in person, so if you have any questions, please feel free to find them after the presentation. Cool. So what we kind of wanted to get across here today, especially for all the web developers out there, is WebAssembly is ready now for primetime production applications. We're super excited to see four major browser engines already ship this, Edge ship last week, so we have Edge, Safari, Firefox, and of course Chrome shipping this now. But also something to keep in mind is that it's not just desktop browsers. It's a mobile thing too. So Safari and iOS 11, as well as Chrome on Android, both support WebAssembly. So you can build highly performant applications using native code for mobile devices, which of course means faster execution time, which means less battery usage. So this is why it's a really exciting technology. Not just that, but not only the browser vendors, but there are other large companies working with WebAssembly now. So we've seen that Unity and Epic are both using it, so it's a true game changer for the web. We also have Autodesk releasing AutoCAD using WebAssembly. So these large players are using it because they realize this is kind of a next-generation, high-performance web application environment, and you should be taking advantage of it too. Because using WebAssembly, you'll build better applications that will delight your users. Thank you.