MEAP Edition Manning Early Access Program WebAssembly in Action Version 1

Transcription

1

2 MEAP Edition Manning Early Access Program WebAssembly in Action Version 1 Copyright 2018 Manning Publications For more information on this and other Manning titles go to

3 welcome Thank you for purchasing the MEAP edition of WebAssembly in Action. WebAssembly is an exciting new technology that allows code written in languages like C++, Rust and others to be compiled into WebAssembly modules and run on the web, sideby-side with JavaScript, at near native speeds. In addition, WebAssembly files are compact and load efficient allowing for quick downloads and initialization. WebAssembly is exciting not only because of the performance improvements it can bring or even the code reuse opportunities. This technology is already supported in all modern desktop web browsers (Chrome, Edge, Firefox, Opera, and Safari) as well as many mobile web browsers. In addition, the browser makers and the WebAssembly working groups are not standing still. They ve been hard at work making improvements to the technology to speed up performance even further and bring additional features. While a lot of information about WebAssembly can be found on the web, it s not always easy to understand how to get started. In addition, being a technology that has advanced rapidly, some of the information that exists is no longer up to date. By the end of the book you should understand: What WebAssembly is, the problems it solves, how it works, and the various ways that WebAssembly modules can be created using C or C++ and the Emscripten toolkit The various ways that JavaScript code can communicate with WebAssembly and viceversa How multiple modules can talk to each other How WebAssembly modules work in NodeJS WebAssembly files are in a binary format but when shown in the browser s developer tools, the equivalent WebAssembly Text Format is displayed. You will examine the WebAssembly Text Format in this book as well. If you have any questions, comments, or suggestions, please share them on Manning s Author Online forum for my book. C. Gerard Gallant

4 brief contents PART 1: FIRST STEPS 1 Meet WebAssembly 2 Creating your first WebAssembly module PART 2: WORKING WITH MODULES 3 Creating a WebAssembly module that JavaScript talks 4 Creating a WebAssembly module that talks to JavaScript PART 3: ADVANCED TOPIC 5 Allowing multiple WebAssembly modules to talk to each other 6 Running code in a separate thread from the UI in a browser 7 Working with WebAssembly modules in NodeJS PART 4: DEBUGGING AND TOOLS 8 The WebAssembly Text Format 9 Debugging 10 Tools 11 Future WebAssembly improvements that are in the works APPENDIXES: A WebAssembly Known sections B Installation & tool setup C ccall, cwrap, and direct method calls

5 1 1 Meet WebAssembly This chapter covers What WebAssembly is The problems that WebAssembly solves How WebAssembly works What makes WebAssembly secure The languages that can be used to create a WebAssembly module When it comes to web development, one thing that s top of mind for most web developers is performance. From how fast the webpage loads to how responsive it is overall. That s because a number of studies have shown that if your webpage doesn t load within three seconds, 40% of your visitors will leave. That percentage increases for every additional second it takes your webpage to load. How long it takes your webpage to load isn t the only issue. Based on a Google article, if your webpage has poor performance, 79% of your visitors say they re less likely to purchase from your website again ( As web technologies have advanced, there s been a push to move more and more applications to the web. This has presented developers with another challenge because web browsers support only one programming language: JavaScript. Having only one programming language across all browsers is a good thing in one sense because you only have to write your code once and you know that it will run in each browser. You still have to test in each browser that you intend to support because browser vendors sometimes implement things slightly different compared to other browsers. Also, sometimes one browser vendor won t add a new feature at the same time as other vendors. Overall

6 2 though, having one language to support is easier than four or five. The downside of browsers supporting only JavaScript, however, is that the applications we want to move to the web weren t written in JavaScript but rather with languages like C++. JavaScript is a great programming language but we re now asking it to do more than it was originally designed to do, like heavy computations for games for example, and we re asking for it to run really fast. 1.1 What is WebAssembly? In 2017, all four major browser vendors (Google, Microsoft, Apple, and Mozilla) updated their browsers with support for the MVP (Minimum Viable Product) of WebAssembly, or Wasm for short. WebAssembly is a low-level assembly-like language that can run at near native speeds in all modern desktop web browsers as well as many mobile web browsers. WebAssembly files are designed to be compact and, as a result, can be transmitted and downloaded fast. The files are also designed in such a way so that they can be parsed and initialized quickly. WebAssembly is designed as a compile target so that code written in languages like C++, Rust, and others can now run on the web. Back-end developers can leverage WebAssembly to improve code reuse or to bring their code to the web without having to rewrite it. Web developers also benefit with the creation of new libraries, improvements to existing libraries, and the opportunity to improve performance in computationally heavy sections of their own code. Although the primary use of WebAssembly at the moment is within web browsers, WebAssembly is also being designed with portability in mind, so that it can be used outside of the browser as well. 1.2 What problems does it solve? One of the biggest issues that WebAssembly aims to solve is performance from how long it takes to download your code to how quickly the code executes Performance improvements With programming languages, rather than writing code in the machine language that the computer s processor understands, 1s and 0s (also referred to as native code), you usually write something that s closer to a human language. While it s easier to work with code that s abstracted from the fine details of a computer, computer processors don t understand your code so, when it comes time to run it, you have to convert what you wrote into machine code. JavaScript, the programming language available in all browsers, is what s known as an interpreted programming language. An interpreted language reads the code that you wrote as it s executing and translates those instructions into machine code on the fly.

7 3 The advantage of languages that are interpreted is that there s no need to compile the code ahead of time which means the code starts running sooner. The downside, however, is that the interpreter has to convert the instructions to machine code every time the code is run. If your code is doing a loop for example, each line of that loop has to be interpreted every time the loop is executed. Because there s not always a lot of time available during the interpretation process, optimizations are not always possible either. Other programming languages, like C++, are not interpreted. With these types of languages, you need to convert the instructions to machine code ahead of time and, to do this, there are special programs called compilers that handle the task. With compiled programming languages, it takes a bit of time up front to convert the instructions to machine code before you can run them but the advantage is that there s more time available to run optimizations on the code and, once it s compiled to machine code, it doesn t have to be compiled again. Over time, JavaScript has gone from simply being a glue language that ties components together, and where it was only expected to be short lived, to a language that is now used by many websites to do complex processing, can easily involve hundreds to thousands of lines of code and, with the rise of single page applications, the code can often be long lived. The internet has gone from having websites that just displayed some text and a few pictures to very interactive websites and even websites that are called web applications because they re similar to desktop applications but running in a web browser. As developers continued to push the limits of JavaScript, some noticeable performance issues came to light. Browser makers decided to try and find a middle ground where you still get the advantages of an interpreter, where the code starts running as soon as it gets called, but also have code that runs faster when it s being executed. To make the code faster, they introduced a concept called JIT (Just in Time compiling) where the JavaScript engine monitors the code as it runs and, if a section of code is used enough times, the engine will attempt to compile that section of code into machine code so that it can bypass the JavaScript engine and use the lower-level system methods instead which are much faster. The reason why the JavaScript engine needs to monitor the code a number of times before it gets compiled to machine code is because JavaScript is also a dynamic programming language. In JavaScript a variable can hold any type of value. For example, a variable can hold an integer initially but later the variable can be assigned a string. Until the code is run a few times, a browser doesn t know what to expect. Even once compiled, the code still needs to be monitored because there s still a chance that something will change and the compiled code for that section would need to be thrown out and the process started again Faster startup times compared with JavaScript WebAssembly is not designed to be written by hand and it s not intended to be read by humans. When code is compiled to WebAssembly, the resulting bytecode is represented in a binary format, rather than a text format, which reduces the file size allowing it to be transmitted and downloaded fast.

8 4 The binary file is designed in such a way that validation of the module can be made in a single pass. The structure of the file also allows for different sections of the file to be compiled in parallel. By implementing just-in-time compilation, browser makers have made a lot of progress in improving JavaScript performance, but the JavaScript engine can compile JavaScript to machine code only after the code s execution has been monitored several times. WebAssembly code, on the other hand, is statically typed, which means the types of values that the variables will hold are known ahead of time. Because of this, WebAssembly code can be compiled to machine code from the beginning, without having to be monitored first, so performance improvements are seen from the very first time the code is run. Since the release of the MVP, browser makers have already found ways to improve WebAssembly s performance further. One performance improvement was the introduction of something they call streaming compilation, which is the process of compiling the WebAssembly code to machine code as the file is being downloaded and received by the browser. Streaming compilation allows for a WebAssembly module to be initialized as soon as it finishes downloading which speeds up the module s startup time considerably Ability to use languages other than JavaScript in the browser Up until this point, for a language other than JavaScript to be able to target the web, the code had to be converted to JavaScript. Converting code from one language to another is known as transpiling. JavaScript is a programming language and was not intended to be a compiler target. WebAssembly, on the other hand, is designed to be a compiler target from the beginning which means developers who want to use a particular language for web development will be able to do so without having to transpile their code into JavaScript. Because WebAssembly isn t tied to the JavaScript language, improvements can be made to the technology more easily and without worrying about interfering with how JavaScript works. This independence should result in the ability to make improvements to WebAssembly much faster. For the MVP of WebAssembly, focus was given to C and C++ as the languages that could target WebAssembly but Rust has since added support and several other languages are experimenting with WebAssembly Opportunity for code reuse Being able to take code written in languages other than JavaScript and compile them to WebAssembly gives developers more flexibility when it comes to code reuse. Now, something that would have had to be rewritten in JavaScript can still be used on the desktop or server but can also run in the browser.

9 5 1.3 How does it work? As the following diagram illustrates (figure 1.1), with JavaScript, the code is included in the website and is interpreted as it runs. Because JavaScript variables are dynamic, looking at the add method in the illustration, it s not obvious what type of values you re dealing with. The variables a and b could be integers, floats, strings, or even a combination where one variable could be a string and the other a float for example. The only way to know for sure what the types are is by monitoring the code as it executes which is what the JavaScript engine does. Once the JavaScript engine is satisfied that it knows the variable s types then it can convert that section of code into machine code. Figure 1.1 JavaScript compiled to machine code as it executes WebAssembly is not interpreted but rather it s compiled into the WebAssembly binary format by a developer ahead of time, as the following high-level illustration shows (figure 1.2). Because the variable types are all known ahead of time, when the browser loads the WebAssembly file, the JavaScript engine doesn t need to monitor the code. It can simply compile the binary format of the code straight into machine code. Figure 1.2 C++ being turned into WebAssembly and then into machine code in the browser

10 Overview of how compilers work In section 1.2.1, we talked briefly about how developers write code in a language that s closer to a human language but computer processors only understand their machine language. As a result, the code you write has to be converted into machine code in order for it to be executed. What we didn t mention is that each type of computer processor has its own type of machine code. It would be inefficient to compile each programming language directly to each version of machine code. Instead, what usually happens is shown in figure 1.3, where a part of the compiler, referred to as the front-end, converts the code you wrote into an intermediate representation (IR). Once the IR code has been created, another part of the compiler referred to as the back-end, takes the IR code, optimizes it, and then turns it into the desired machine code. Figure 1.3 Compiler front-end and back-end diagram Because a browser can run on a number of different processors (from desktop computers to smart phones and tablets for example), it would be tedious to distribute a compiled version of the WebAssembly code for each potential processor. What you do instead is shown in figure 1.4, where you take the IR code and run it through a special compiler that converts it into a special binary bytecode and places that bytecode in a file with a.wasm extension.

11 7 Figure 1.4 Compiler front-end with a WebAssembly back-end diagram The bytecode in your Wasm file isn t machine code yet. It s simply a set of virtual instructions that browsers, who support WebAssembly, understand. As shown in figure 1.5, when the file is loaded into a browser that supports WebAssembly, the browser verifies that everything is valid and then the bytecode is compiled the rest of the way into the machine code of the device that the browser is running on. Figure 1.5 Wasm file loaded into a browser and then compiled to machine code diagram Loading, compiling, and instantiating a module At the time of writing, the process of downloading the Wasm file into the browser and having the browser compile it is done by making some JavaScript method calls. There s a desire to allow WebAssembly modules to interact with ES6 modules in the future, including the ability to be loaded though a special HTML tag (<script type="module">) but this isn t yet available for WebAssembly modules. Before the module s binary bytecode can be compiled, it needs to be validated to make sure that the module is structured correctly, that the code cannot do anything that isn t permitted, and that the code cannot access memory that the module doesn t have access to. Checks are also made at runtime to ensure that the code stays within the memory that it has been given access to. The Wasm file is structured in such a way so that validation can be

12 8 made in a single pass to ensure that the validation process, compilation to machine code, and then instantiation is as fast as possible. Once a browser has compiled the WebAssembly bytecode into machine code, the compiled module can be passed to a Web Worker (we ll dig into Web Workers in chapter 6 but, for now, Web Workers are a way to create threads in JavaScript) or to another browser window. The compiled module can even be used to create additional instances of the module. Once a Wasm file has been compiled, it has to be instantiated before it can be used. Instantiation is simply the process of receiving any import objects that are needed, initiating the elements of the module, calling the start method if a start method was defined, and then finally returning the instance of the module to the execution environment. WebAssembly versus JavaScript Up until now, the only language allowed to run within the JavaScript virtual machine (VM) was JavaScript. When other technologies were tried over the years, like plug-ins, they needed to create their own sandboxed VM, which increased the attack surface and increased the use of computer resources. For the first time ever, the JavaScript VM is being opened up to allow WebAssembly code to also run in the same VM. WebAssembly code being able to be run in the same VM as JavaScript has several advantages. One of the biggest advantages to reusing the JavaScript VM for WebAssembly is that the VM has been heavily tested and hardened against security vulnerabilities over the years. If a new VM was created, it would undoubtedly have some security issues to iron out. WebAssembly is being designed as a complement to JavaScript and not as a replacement. Although we ll likely see some developers try to create entire websites using only WebAssembly, that likely will not be the norm. There will be times where JavaScript will still be the better choice. There will also be times when a website may need to include WebAssembly for access to faster calculations or for lower level support. For example, SIMD (Single Instruction, Multiple Data) the ability to process multiple data with a single instruction) was being built into the JavaScript of several browsers but the browser vendors decided to deprecate the JavaScript implementation and make SIMD support available only via WebAssembly modules. As a result, if your website needs SIMD support, you would need to include a WebAssembly module to communicate with. When programming for a web browser, there are basically two main components. The JavaScript VM, which the WebAssembly module runs in, and the Web APIs (for example, DOM, WebGL, Web Workers, and so on). Being an MVP, there are some things missing from WebAssembly. Your WebAssembly module can communicate with JavaScript but doesn t yet have the ability to talk directly to any of the Web APIs. There is a post-mvp feature being worked on called Host Bindings which will give WebAssembly direct access to the Web APIs. In the meantime, however, modules can interact with the Web APIs indirectly by calling into JavaScript and having JavaScript perform the action needed on the module s behalf Structure of a WebAssembly module WebAssembly currently has only four available value types: 32-bit integers (i32)

13 9 64-bit integers (i64) 32-bit floats (f32) 64-bit floats (f64) Boolean values are represented using a 32-bit integer where 0 is false and a non-zero value is true. All other value types, like strings for example, need to be represented in the module s linear memory. Figure 1.6 represents the basic structure of the WebAssembly binary bytecode Figure 1.6 Representation of the basic structure of the WebAssembly binary bytecode

14 10 The main unit of a WebAssembly program is called the module and we use the term module for both the binary version of the code as well as the compiled version in the browser. A WebAssembly module isn t something that s expected to be created by hand, but having a basic understanding of how the module is structured, and how it works under the hood, does come in handy because we do interact with certain aspects of it during initialization and during the module s lifetime. PREAMBLE A Wasm file starts out with what s called the preamble which contains a magic number (0x00 0x61 0x73 0x6D which is \0asm ) that distinguishes a WebAssembly module from an ES6 module (ES is shorthand for ECMAScript and 6 is the version. ECMAScript is the official name for JavaScript). The magic number is then followed by a version (0x01 0x00 0x00 0x00 which is 1). One of the goals with WebAssembly is to keep everything backwards compatible as new features are being added and to not have to increase the version number. If there ever happens to be something that cannot be implemented without breaking things then the version number will be increased. KNOWN SECTIONS Following the preamble, a module can have several sections but each section is optional so you could technically have an empty module with no sections. There are two types of sections available: Known sections and Custom sections. Know sections can be included only once. Custom sections, on the other hand, can appear anywhere in the module (before, in between, or after the known sections), any number of times, and multiple custom sections can even reuse the same name. (For more information on Known sections, see appendix A.) A module can also have zero or more Custom sections. A custom section provides a developer with a way to include data inside the module for uses that do not apply to the sections defined above. CUSTOM SECTIONS Unlike with the known sections, if a custom section isn t laid out correctly it won t trigger a validation error. Custom sections can be loaded lazily by the framework which means the data they contain might not be available until some point after the initialization of the module. For the MVP of WebAssembly, a custom section called name was defined. The idea with this section is that you could have a debug version of your WebAssembly module and this section would hold the names of the functions and variables in text form to use when debugging. Unlike with other custom sections, this section should only appear once and only after the Data section.

15 WebAssembly Text Format WebAssembly has been designed with the openness of the web in mind. Just because the binary format isn t designed to be written or read by humans doesn t mean that WebAssembly modules are a way for developers to try and hide their code. Actually, quite the opposite is true. A text format that uses s-expressions has been defined for WebAssembly that corresponds to the binary format. The text format will allow for the View Source of the code in a browser, for example, or it can be used for debugging purposes. It s even possible to write s-expressions by hand and, by using a special compiler, compile the code into the WebAssembly binary format. Because the WebAssembly Text Format will be used by browsers when you choose to View Source and for debugging purposes, having a basic understanding of the text format will be useful. For example, since all sections of a module are optional, you could define an empty module using the following s-expression: (module) If you were to compile the (module) s-expression, into the WebAssembly binary format and look at the resulting binary values, the file would only contain the preamble bytes ( d the magic number, and the version number). In section we talked about the four value types available in a WebAssembly module and included the terms i32, i64, f32, and f64. These terms are actually the text format equivalent to the binary opcodes (0x7f, 0x7e, 0x7d, and 0x7c respectively). LOOKING AHEAD In chapter 7, you ll create several WebAssembly modules using only the text format, so that you ll have a better idea of what you re looking at if you ever need to debug a module in a browser for example. 1.4 How is WebAssembly secure? One of the ways that WebAssembly is secure is due to it being the first language to ever share the JavaScript VM. The JavaScript VM has had years of hardening and security tests to make it secure. WebAssembly modules don t have access to anything that JavaScript doesn t have access to and will also respect the same security policies as JavaScript which includes enforcing things like same-origin policy. Unlike a desktop application, a WebAssembly module doesn t have direct access to the memory of the device. Instead, the runtime environment passes the module an ArrayBuffer during initialization. The module uses the ArrayBuffer as linear memory and the WebAssembly framework checks to make sure that the code is operating within the bounds of the array. A WebAssembly module doesn t have direct access to items, like function pointers, that are stored in the Table section. The code asks the WebAssembly framework to access an item based on its index. The framework then accesses the memory and executes the item on the code s behalf. In C++, the execution stack is in memory along with the linear memory and, although the C++ code isn t supposed to modify the execution stack, it s possible to do so through the use

16 12 of pointers. WebAssembly s execution stack is also separate from the linear memory and is not accessible by the code. 1.5 What languages can I use to create a WebAssembly module? To create the MVP, the initial focus of WebAssembly was on the C and C++ languages but Rust has since added support for WebAssembly. It s also possible to write code using the WebAssembly Text format, which uses s-expressions, and compile that into WebAssembly using a special compiler. Right now, the MVP of WebAssembly does not have garbage collection (GC) which limits what some languages can do. Garbage collection is being worked on as a post-mvp feature but, until it arrives, several languages are experimenting with WebAssembly by either compiling their VM to WebAssembly or, in some cases, by including their own garbage collector. The following are several languages that are experimenting with WebAssembly support: AssemblyScript is a new compiler that takes TypeScript and turns it into WebAssembly. Converting TypeScript makes sense considering TypeScript is typed and currently transpiles to JavaScript already. TeaVM is a tool that transpiles Java to JavaScript but can now also generate WebAssembly. Blazor originally started out as a proof-of-concept to bring C# single page applications to the browser. Although still experimental, in February 2018, Blazor became an official ASP.NET project. Blazor uses Mono (an open-source version of the Microsoft.NET framework that is cross-platform to allow.net/c# code to run on a variety of devices including Android, Linux, and macos) as its base which is around 4MB in size. That is quite large but they believe they can reduce that size. For now, the Blazor team is testing using WebAssembly in two ways to try and determine which way would work best for their needs. The first approach that is being tested is porting the VM itself to WebAssembly and having the C# code interpreted. The second approach that the Blazor team is testing is turning all C# code into WebAssembly modules and having the Mono code available for garbage collection. 1.6 Where can I use my module? In 2017 all of the modern browser makers released versions of their browsers that support the MVP of WebAssembly. The desktop browsers that support WebAssembly are Chrome, Edge, Firefox, Opera, and Safari. Several of the mobile web browsers that also support WebAssembly are Chrome, Firefox for Android, and Safari. As mentioned at the beginning of this chapter, WebAssembly was designed with portability in mind so that it can be used in multiple locations, not just in a browser. One of the non-

17 13 browser locations that WebAssembly modules are also supported in is NodeJS starting with version 8. NodeJS is a JavaScript runtime built using Chrome s V8 JavaScript engine that allows JavaScript code to be used server-side. Similar to how many developers see WebAssembly as an opportunity to use code that they are familiar with in the browser, rather than JavaScript, NodeJS gives the opportunity for developers who prefer JavaScript to also use it on the server-side. WebAssembly isn t a replacement to JavaScript but rather a compliment to it. There are times where using a WebAssembly module will be a better choice and other times where using JavaScript will be the better choice. Running in the same virtual machine as JavaScript allows both technologies to leverage each other. WebAssembly will open the door for developers, who are proficient in languages other than JavaScript, to be able to make their code available on the web. It will also allow web developers, who may or may not know how to code in languages like C or C++, to gain access to newer and faster libraries and potentially with features not available in the current JavaScript libraries. In some cases, WebAssembly modules might be used by libraries to speed up execution of certain aspects of the library and, other than faster code, the library would work the same as it always has. The most exciting thing about WebAssembly is that it s already available in all major desktop browsers, in several major mobile browsers, and even outside of the browser in NodeJS. 1.7 Summary As you saw in this chapter, WebAssembly brings a number of improvements with many being around performance as well as language choice and code reuse. Some of the key improvements that WebAssembly brings are the following: Faster transmission and download times because of the smaller file sizes due to the use of a binary encoding. Due to the way the files are structured, they can be parsed and validated quickly. Also because of how they re structured, portions of the file can be compiled in parallel. With streaming compilation, WebAssembly modules can be compiled as they re being downloaded so that they re ready to be instantiated the moment the download completes speeding up load time considerably. Faster code execution for things like computations due to the use of machine level calls rather than the more expensive JavaScript engine calls. Code doesn t need to be monitored before it s compiled to determine how it s going to behave. The result is that code runs at the same speed every time it runs. Being separate from JavaScript, improvements can be made to WebAssembly faster because it won t impact the JavaScript language. The ability to use code written in a language, other than JavaScript, in a browser.

18 14 Increased opportunity for code reuse by structuring the WebAssembly framework in such a way that it can be used in the browser and outside of the browser.