Build the future of the web with WebAssembly and more (Google I/O '18)

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

Sweet, I really look forward to poorly coded WebAssembly adverts

πŸ‘οΈŽ︎ 14 πŸ‘€οΈŽ︎ u/[deleted] πŸ“…οΈŽ︎ Jun 10 2018 πŸ—«︎ replies
Captions
[MUSIC PLAYING] THOMAS NATTESTAD: Hello, everyone. Is everyone hearing me? Hey. AUDIENCE: Hey. [APPLAUSE] THOMAS NATTESTAD: My name is Thomas, and I'm the product manager for V8 and WebAssembly on Chrome. This is my second talk ever like this, but I'm really thinking it might also end up being my last talk ever if the Google Assistant gets any smarter than it already is. Right now, it's making phone calls and I feel like, soon, it'll end up doing all the talking for us, which let's be honest, is the real end goal here anyways. Right? Well, anyways. I joined the WebAssembly team a little while ago and, since then, I've been learning more and more about WebAssembly and what it enables on the web. And as I learned more, I started getting more and more excited about how it could change not only what we can create on the web, but also how we create it. So what is WebAssembly anyways? Well, WebAssembly is a new low-level binary format for the web. This means that it's close to the CPU machine code that your computer understands, and it has all the security that we've come to expect from executing code on the web. It's compiled from other languages, which means that you can write something like C++, and then compile it into WebAssembly. Because it's so low-level and compiled from other languages, it also offers maximized performance. In this talk, I want to talk to you about why WebAssembly is such a game changer for how we create things on the web. Then I want to actually jump into some code, and show you how you can be writing WebAssembly today. Then I'll showcase some of the amazing applications that we've seen on the web already utilize WebAssembly to great effect. And then I'll close out by showcasing a little bit of what we still have on the roadmap for WebAssembly features. OK. So what are the actual advantages of WebAssembly, and why might you want to use it? Well, first off is performance. Because WebAssembly was designed for speed, it offers better performance than JavaScript can. JavaScript is a dynamic language, which is great to making it easy to write, but it also means that the JavaScript engine has to optimize that JavaScript as it's being executed on the page. WebAssembly is optimized before it actually hits the browser, and this allows it to offer better and more reliable performance than JavaScript. Secondly, WebAssembly offers amazing portability. Because you can compile from other languages, you can port not only your own applications to the web, but also the incredible wealth of C++ libraries and open source applications that exist out there. And because C++ specifically is supported on practically every platform, including iOS and Android, you can now write C++ as the common language across your different web and mobile deployments by leveraging WebAssembly. Lastly, and potentially most exciting to many of you out there, is the prospect of more flexibility when writing for the web, specifically the ability to write in different languages. Since the web's inception, JavaScript has been the only fully supported option for developers who want to write logic for the web. But now, with WebAssembly, you have more choice. The current fully supported languages are C, C++ and Rust, but there are many other languages that are experimenting with adding support, including Kotlin and .NET, both of which have shipped experimental support for WebAssembly. So why do these powers and abilities in WebAssembly actually matter in the first place, and why do we want to do interactivity on the web? Well, to really explain that, I want to go back to a time when we didn't have any interactivity on the web whatsoever. This is the first-ever web page, published by Tim Berners-Lee in 1991. As you can see, in its original form, the web was really just slightly formatted text meant only for consumption of information. Aside from clicking on links, there was literally nothing you could interact with at all. Then JavaScript comes along, and is famously created in a single 10-day hackathon. This brings some level of basic code execution to the browser. And with this foundation of JavaScript, we see the first real web applications actually come to the web. These include examples like Gmail, but also things like MapQuest and eBay. As interest grew in what you could do with interactivity on the web, we saw an incredible explosion of developet-created libraries. And these were libraries such as jQuery for doing DOM manipulation, Angular and other popular frameworks for organizing your page content on the client, and also things like three.js and D3.js to make beautiful and interactive visualizations. And there are so many more other libraries that expand what we can collectively create on the web. One of my favorite things about working on the web platform is that you have this easy ability for any developer to package up some functionality that they are the expert on, and then share that capability with everyone, allowing us to build amazing things that we wouldn't have been able to otherwise. Browsers also continued to advance during this time. You had things like V8 revolutionizing JavaScript performance to expand what you could actually feasibly create with JavaScript. You also had capabilities, like WebGL bringing interactive graphics, HTML5 bringing new capabilities to the DOM and, just recently, with service workers allowing you to do offline and so much more. All of these technologies and others continue to expand what was actually possible to do on the web. And the industry responded in kind by bringing more and more of their applications to the web. We saw examples like Google Docs, Trello, and even Microsoft Office 365 all start to move to the web. But why? Why was there such an appetite for application and interactivity on the web in the first place? Why didn't we just leave interactivity to the native operating system, where developers could have full access to everything and choose whatever language they wanted to be developing in? Well, there are three fundamental powers of the web that actually make it a fantastic space specifically for applications. First off is linkability. This means that your app is not only accessible by a single click on any other page, but you can even share your application or a specific document for your application through a single shareable clickable string. Secondly, the web application is ephemeral. And this means that your users don't have to worry about the process of going and installing your application, or whether the application is trustworthy. The application is securely delivered in a sandboxed environment as soon as the user needs it. Lastly, the web is the only truly universal platform, meaning that your application is accessible by anyone on any device. This also means that you can maintain a single code base and be sure that every user can access your application-- something I think all of us can really appreciate. And so because of these incredible powers that the web offers for interactivity, we went from this small scripting language all the way to this incredibly powerful and popular platform filled with amazing applications and capabilities, but which was still fundamentally powered by the same scripting language that was never really designed to do all of this in the first place. That's why the web browsers came together to create WebAssembly, and it's why WebAssembly is now shipping in all four major browsers, making it the first runtime since JavaScript was created more than 20 years ago to be shipped in every browser. WebAssembly isn't meant to replace JavaScript though. The two were designed to interoperate. And within Chrome, it's actually the same team working on both. Rather, WebAssembly is the foundational power that unlocks the ability to create new native-like experiences on the web, and it even gives you a porting path to move your applications to the web without having to rewrite them. OK. So hopefully that gives you a little bit of a sense of what WebAssembly can offer, and gets you as excited as I am to jump into some code. I want to start off by showcasing the final result of what you can actually build right here at I/O by going and checking out the codelab that we have available to you, or you can access it from bit.ly/wasmio2018. And without further ado, here it is. This is a hourglass example where we've taken the chipmunk physics engine, which is the one utilized by Cocos2d, and then we've leveraged WebAssembly to bring it into the browser. We used the engine to simulate this running hourglass where every single grain of sand that you see in the hourglass is actually its own SVG DOM element. And if I want, I can actually play with it. And you can see this for yourself when you go and check out the code lab. But you can turn it over and have all of the little SVG elements respond accordingly. OK. So let's have a look at some actual code and dig in. The first thing I want to mention is WebAssembly's amazing toolchain, Emscripten. Some of you may know him Emscripten from when it was used to turn C++ into asm.js, which was a precursor to WebAssembly. Emscripten has since morphed into a fantastic toolchain for WebAssembly. It's what you'll use to compile your source file into the WebAssembly format, but it also does so much more for you. It offers a lot of automatic translation, such as translating your OpenGL API calls into their WebGL alternatives, and it also simulates an entire file system for your ported applications to utilize. It also includes the C standard library, and provides alternatives to Linux build tools, such as configure and make. You can read all the details about Emscripten at Emscripten.org. OK. So let's look at some code. Here I have the computational equivalent of a hello world, which is a simple C function that calculates the nth Fibonacci number. You'll notice these two additional pieces at the top. This top line is used to include the Emscripten library, and then this second line is used to tell Emscripten that we're going to be calling this function, and that it shouldn't remove this function even if it seems to be unused. This is the command that we'll use to actually compile our file, and we can step through each of the pieces. You'll first use emcc to actually execute the Emscripten compiler. Then we'll pass in -s WASM=1 to make sure that Emscripten will output WebAssembly since it still outputs asm.js by default, though this will be changing to defaulting to WebAssembly soon. We also want to name our output file, so we'll pass in -0 fib.js. And then finally, we'll pass in our input file, fib.c. And this is the whole command that you need to execute. emcc will then give us back two different files, fib.wasm and fib.js. fib.wasm holds the minimal WebAssembly binary for a Fibonacci function, while fib.js holds some helper code to load the WebAssembly module and set it up properly. It's worth noting here that Emscripten has many different ways to output code based on your needs. In this example, we're having it output this js helper file, but you can even have it output an entire HTML page with a terminal simulator in it to help you get started. These are both useful ways to get started, but they include some code that might not be necessary in every application. And if you're trying to create something that's truly production grade, it will be important for you to dig into the Emscripten library and documentation to figure out what to include. All right. So next, let's have a look at the HTML page that you need to use in order to actually include this. At the top line, we'll just use a simple script tag to import our fib.js. And including this fib.js is what gives us access to this module object. The module object is a central part of Emscripten, and it's how you'll access Emscripten functionality. This module object comes with a function called cwrap, which will return a JavaScript function that allows us to call our compiled WebAssembly function while taking care of all of the input and output type conversion for us. And then we can actually just call that function directly. And if we pass in 12, we correctly see that we get back out 233. Awesome. So this is a basic example of how you can communicate between WebAssembly and JavaScript, but there are also other ways for you to communicate between the border of JavaScript and WebAssembly. Which one you choose will ultimately depend on your own preference and the architecture of your application. All right. So for the next example, I want to start off and show a brand new way of how you can communicate between this JavaScript and WebAssembly border. Our end goal will be to make this animating, weirdly spinning ball painted onto a canvas by utilizing some web APIs, but with logic controlled in C++. So let's start off, and we'll create a ball.cpp file. And you'll notice, once again, we include the Emscripten library to get all the benefits that provides. Next, let's talk about this EM_JS function, which seems to have JavaScript code inside of it despite this being a C++ file. Well, the reason why we can do this is because EM_JS is a special macro known by the Emscripten library. The format is that you first pass in your return type, then the name of the function, and then the list of arguments that you'll be calling that function with. The great advantage that EM_JS gives is that you can now write the JavaScript that you know and love while staying in that same C++ file. So in this piece of JavaScript, we just simply find the canvas, wrap the context, and paint a red circle at the given location with a given radius. We then include a classic main function that calls our function, drawCircle, passing in the given location and radius. Thanks to EM_JS, Emscripten takes care of converting these inputs into what will be used inside of the JavaScript function, and then calling that JavaScript function. You can also find more documentation on how EM_JS works at Emscripten.org. All right. So this is the command that we're going to use to compile this piece of code and, this time, we're going to get a little bit more fancy and optimized with it. We'll pass in this -03, which will tell the Emscripten compiler to optimize aggressively, including the removal of unused code. Because we're telling Emscripten to remove unused code, we also have to explicitly tell Emscripten that we're going to want our old friend cwrap to still be included since we'll be utilizing that later. All right. Now we have, again, an index.html file. Dirt simple this time. It just includes the canvas tag, and then we load our ball.js script. You'll notice that we don't actually have to call our main function at all, and this is because we named it main, and Emscripten knows to execute that on startup because it's a common C++ pattern. And boom, you put all that together, and you have your single C++ file that calls a JavaScript function, and then paints this ball onto the canvas. This is great. But so far, the only thing that we're actually doing in C++ logic is calling into a JavaScript function. So let's do something a little bit more interesting. We want to start by animating this ball. And in order to animate it, we have to clear the canvas each frame. So we'll just make another EM_JS function. We'll pass in void return type, name and clear canvas, and no arguments. Inside of this, we're just grabbing the context again and clearing it completely. OK. So we want to actually start taking advantage of some of this C++ logic that we can implement, and we'll start off by including math.h. Because Emscripten includes the C standard library, we get full interoperable access to this math library without having to worry about porting it ourselves. Then, further down in our file, we'll also have this static float t in order to keep track of time, and we'll swap out our main function for an update function that we'll be calling repeatedly. Just like in our last example, we'll utilize EMSCRIPTEN_KEEPALIVE to make sure that Emscripten doesn't get rid of this function, but you'll also notice that we have this extern C wrapper around our function. This is included so that Emscripten won't do any name mangling while compiling our C++ function. The reason we didn't have to do this in the previous example is because that was just C code not C++. Any C++ function whose name you want to remain unchanged and referenceable from JavaScript needs to be inside of this extern C wrapper. All right. And then inside this inner logic, we just update our time variable, call our clear canvas function, and then draw a drawCircle function with some funky sign math that we get from the math library. Awesome. So now, let's jump into our index.html page, and actually set this up so that we'll call our update function on a continual basis. To do this, we'll once again take advantage of Emscripten understanding what the module object is. We'll define this module object. Then we set a pre-run function on it. And this pre-run function simply utilizes request animation frame to call our update function that we, once again, get from cwrap. And then at the bottom, we'll also include our ball.js script. And just like that, you have this wonderfully weird animation being controlled by C++ logic. Great. So now that we know the basics of writing some WebAssembly, let's have a look at what some developers have already accomplished by utilizing WebAssembly. One company that's been able to utilize the performance of WebAssembly and the linkability of the web is Figma. Figma is a powerful cloud-based screen design platform that makes it easy for teams to work in sync on a design through a single URL. Designers, product managers, engineers, and others involved in the design process can now iterate and design on a single place to gather feedback, without having to worry about exporting documents or managing the application. It's all right there instantaneously. It used to be that with native design tools, you had to worry about managing all of your files, whether everyone involved in the process had the right software installed, and whether or not people's operating system even supported the application in the first place. Now you can use the power of links as the single source of truth, while enabling anyone on any device to access your application or a specific document while trusting that it will always be up to date. Great. So let's have a look at how they've actually architectured their application to include WebAssembly, and see if we can learn anything. From the nonperformant part of their rendering, or of their application, they use a modern TypeScript language with the React framework. In the center area of their application, they have a single canvas with all of their logic implemented in C++ through WebAssembly. This section has three different components inside of it. The first is a custom rendering engine where they decode their file format through WebAssembly, and then render it onto the canvas by utilizing WebGL. Secondly is a custom text editor, where they've actually been able to utilize popular open source C++ library, again, by leveraging WebAssembly. And then finally, they have a collaboration system that uses web sockets for fast multi-player editing. By utilizing all of these different advanced tools and features of the web, they're able to create an application experience that is not only highly performant, but also has all of the advantages of being an application on the web. Another great company that I want to talk about that's really been able to leverage the universality and ephemeralness of the web is Construct 3. Construct 3 is a full-blown game engine and editor that allows you to create and export games directly from the browser. Thanks to the ephemeralness, they have an onboarding flow that takes you from their marketing page, loads up the editor, lets you pick the project and be inside of the application in less than a minute. Once you're in the application, you can immediately jump in and start making any edits that you want, maybe adding a little bit of game logic or doing whatever other edits you need to. And then when you're ready, you can also export it directly from inside of the browser. This is an interesting point, because here's where Construct 3 leverages the universality of support for the web platform by enabling their export to different platforms. It actually exports the game as a single web page, and then utilizes basic wrappers around that content to make it appear like a native application. Construct has all of their UI and logic implemented in JavaScript, but utilizes WebAssembly for its audio decoding, as well as poly filling functionality in some older browsers. All right. Another company that I'd like to tell you about is AutoCAD, but instead of me telling you about it, I'd like to invite Marcus O'Brien onto the stage, senior product line manager at AutoCAD, to tell you about the experience himself. MARCUS O'BRIEN: Thanks, Thomas. That's great. [APPLAUSE] Hey, everyone. How's it going? So my name is Marcus O'Brien, and I lead the AutoCAD product management team at Autodesk. So we have a couple of people from AutoCAD in the audience here today, and I'd like to give a shout out to the web team and the mobile team that's come from Tel Aviv specifically for Google I/O. So today, I'd like to tell a short story about AutoCAD's journey to the web. So AutoCAD is a computet-aided design and drafting software application. It's used by the world's most innovative engineers and architects to imagine, design, and make the world around us. It was first released in 1982. It's not a new application. And prior to AutoCAD, design was done by people using pen and paper on drafting boards. The cost of revision was slow, and innovation was slow as a result. So the vision for AutoCAD, from the very beginning, was to reduce the amount of time it takes to innovate, to increase the number of iterations possible within a design process, and to ultimately help designers optimize for the best possible solution to the problems they were trying to solve. And AutoCAD has changed the world continuously as it's evolved over the last 35 years. More than 10 years ago, or more than 10 years after AutoCAD was first introduced, the internet was born. We heard Sir Tim Berners-Lee pioneered this. And AutoCAD was made popular with Mosaic and Netscape and Internet Explorer. AutoCAD first dipped its toe in the water of internet connectivity with AutoCAD 2000I, where I stood for internet. And many years later, we first released in 2010 the AutoCAD web and mobile apps, but really this was just the beginning of the AutoCAD connected story. So now with AutoCAD on desktop, web, and mobile, a new vision was born. This was a vision where we could free our customers, these designers, from their desks so that they could take AutoCAD wherever they go with them to increase their chances at innovating even further, and to add to the workflows. So the AutoCAD web app was intended to allow people to work from anytime, anywhere, and have access to this precision drafting app, whether they're at home or on the go. I just want to tell you that AutoCAD's standard file type is called the DWG file. There are an estimated 2 to 5 million DWG files open today. That's a lot. And there's some 5 billion DWGs on cloud servers today. So the anytime, anywhere access is even more important than it's ever been before. However, as much as we wanted to bring AutoCAD to a browser, we were a little bit limited by the technology that was available at the time. In 2010, we released a flash-based version, which got us kind of a toe in the water, in terms of having a basic editor in a browser. In 2014, we shifted from flash and changed to HTML5 and JavaScript. And this worked, but we realized very quickly that this was not a very scalable way for us to build this precision drafting tool in a browser because we had all the features already in our C++ code base, and we were having to rewrite them in JavaScript for this browser. So it wasn't very scalable. So two years ago, we started exploring what were the options for us to port our common code base to the browser, and we got a number of quick wins early on. So we started to take it more seriously. And the wins kept coming. So one year ago, we were able to release our first beta viewer to our beta customers, where they could view or read native DWGs in a browser. So to put that into context, customers were able to open a 25-year-old drawing file and read it in the browser. About eight months ago, we were able to port our first true feature from AutoCAD core over to our browser. In December, we had the makings of a basic editor with lines, arcs, and circles on WebAssembly, and we released this in beta, as well, to our customers. And then on March 22 of this year, we hit a major milestone. For the first time, we were able to release the AutoCAD web app, and we were finally able to unlock the power of AutoCAD in a browser with zero download and install required. So how did we make this happen? We have the common AutoCAD C++ code base, which we translate with Emscripten, which gets compiled at runtime in the browser. We have our React and TypeScript UI running on the main thread, and it works together with WebAssembly modules running on a web worker to create the AutoCAD web application. But what does this really mean in real terms? So having a shared common C++ codebase means that our C++ developers can develop features and bug fixes across our platforms without ever having to learn JavaScript or other web technologies. And for our customers, it means that they have enhanced cohesive experiences. The feature that you build on desktop, it just works on web. So here's a look at it running in Chrome. You might have seen this on main stage yesterday. So customers familiar with AutoCAD will immediately recognize this. You can see in the canvas here, it's very familiar, and you can see that you've got your crosshairs. It's a very AutoCAD experience. And interacting with it feels like using AutoCAD desktop. You can see the JavaScript UI is giving very user feedback and control to the user, and it's interacting smoothly with the performant WebAssembly canvas that's been ported from our C++ codebase. So overall, building on WebAssembly helped us lock deeper capabilities of our AutoCAD's optimized code base that would have been impossible to rewrite in JavaScript. It cuts our development by orders of magnitude, and in fact, it's more performant than had we developed this in JavaScript alone. So with AutoCAD running on WebAssembly, in addition to our AutoCAD core codebase, our vision for a web app is no longer limited by web technology. So I'm really excited about where we're taking this and the opportunities that we're pursuing, both for AutoCAD and for our customers, in terms of what they can do with AutoCAD in a browser. And with that, I'd like to hand it back over to Thomas. Thanks very much. [APPLAUSE] THOMAS NATTESTAD: Great job. Thank you, Marcus. It's been really amazing to see AutoCAD utilize WebAssembly to gain all the powers of the web, and enable their customers to access AutoCAD anywhere. So now that we've seen some of these different amazing, high performance demanding applications, I want to go back and talk again about libraries. Remembering back to the early stages of the web when we saw that explosion of amazing developer-created libraries, I think we're at a similar infection point now with WebAssembly. Well, I don't have time to show off all the examples, unfortunately. We've seen some amazing developers leverage WebAssembly to make everything from physics engines, facial recognition systems, video editing, and even artificial intelligence. These tools can be packaged up, and then enable all of us to have these capabilities for ourselves. And I'm so excited to see what all of us will be able to build when we unlock these new next generation libraries that are enabled by WebAssembly. We've also seen existing popular libraries start to adopt WebAssembly to maximize their performance. We've seen the Glimmer rendering engine, which is the one utilized by the Ember framework, already start making commits with WebAssembly to improve their performance. OK. So now that we've seen some cool use cases for WebAssembly, learned a little bit of WebAssembly ourselves, I want to show off what we still have in the works. This is some in progress works, so it's not completely refined yet, something that I think will come across in the style of these slides. Probably the most exciting feature that we're working on is Threads, which can double or even quadruple the performance of your application. Modern CPUs ship with several cores, but historically, the web has had very limited access to these additional cores, restricting how performant your application could be compared to native. You get some additional access to these cores through web workers, which are great, but workers can be quite heavy weight, and they only communicate through post message, restricting what use cases they enable. The way WebAssembly threads will work is by using shared array buffer to communicate between the workers at high speed. This also means that existing C++ codebases that utilize P threads, or which rely on blocking, can be ported directly to the web and take full advantage of the benefits that threading provides. We're also improving the way that WebAssembly can talk to the rest of the web browser. Right now, WebAssembly always sits within a sea of JavaScript. And when it wants to make calls to the DOM or to web APIs, like WebGL, it has to go through JavaScript to do so. We're changing that so that WebAssembly can directly hold references to the DOM or web APIs, and communicate without having to go through JavaScript. Looking a bit further ahead, we've also started exploring direct ES module support for WebAssembly. This will improve the ability for JavaScript and WebAssembly to import and interact with modules of the other type without having to do any unnecessary wrapping. Together with letting WebAssembly hold references to the DOM and web APIs, we're substantially improving WebAssembly's interoperability with the rest of the web stack. Also further out is the prospect of adding first-class support for other languages. The reason why C, C++, and Rust are the current fully supported languages is that they manage their own memory and don't have a garbage collection system that manages it for them. As I mentioned earlier, we have seen languages like Kotlin or the .NET framework ship experimental support for WebAssembly. And they've been able to accomplish this by actually compiling down their garbage collector and the rest of their runtime environment to WebAssembly, and then shipping it along with their page. Because of WebAssembly's small size, this doesn't add as much bloat as you might think, but it's definitely not ideal. And you also have to be very careful when making interactions with the DOM or with web APIs to prevent you from leaking memory. We're working on a proposal called the Managed Object Proposal that we hope will add better first party support to these languages and enable them fully in the browser. So that brings me towards the end of my talk. And to close out, I want to really just ask all of you to go out there and build amazing things with WebAssembly. Go port some application to the web. Go create some amazing developer library that will give all of us additional super powers on the web. Whatever you do, and whatever you end up creating, I hope you'll share it with others. I would certainly love to hear about it, and you can tweet me directly, or you can tweet the awesome V8 team that's actually working on all of this functionality @VHAS. Thank you so much. [APPLAUSE] [MUSIC PLAYING]
Info
Channel: Google Chrome Developers
Views: 88,609
Rating: 4.8128815 out of 5
Keywords: type: Conference Talk (Full production);, pr_pr: Google I/O, purpose: Educate
Id: BnYq7JapeDA
Channel Id: undefined
Length: 34min 27sec (2067 seconds)
Published: Wed May 09 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.