[go: up one dir, main page]

WebAssembly is fundamentally changing how new developer capabilities and functionality can be created on the web. In order to maintain browser interoperability, new web capabilities need to go through a rigorous standardization process and cross browser implementations. Decades of major investment has pushed the browser functionality to astonishing heights, but this process can take time and the web doesn’t need to have every capability built in. After years of investing in lower level capabilities that act as building blocks for higher level functionality, we are seeing a new dawn of expanded functionality at a dramatically expanded pace.

WebAssembly 

WebAssembly is a portable bytecode format compiled from other languages to offer maximized performance. By leveraging WebAssembly, developers can take libraries and functionality from other platforms and performantly bring them to the web, without requiring any reimplementation. WebAssembly also offers advanced computation primitives like parallelizable threads and Single Instruction Multiple Data (SIMD) that enable it to maximize the performance from the CPU. 


With WebAssembly offering portability plus performant access to the CPU the web now has the necessary low level building blocks for a huge variety of new functionality to be built. All of this, of course, rests on the incredible foundation that is the full web platform—full of powerful capabilities, rendering methods, and much more. 

Real world examples 

We’ve dedicated a whole blog post to showcasing just a small proportion of the new functionality being made available thanks to WebAssembly. 


Some of these examples are functionality that tried to go through the standard process but didn’t make it for a variety of reasons. Other examples are being actively standardized and implemented across browsers. 

Advantages of this new development paradigmFaster iteration speed

Because functionality doesn’t have to go through standards and get approval before shipping, iteration cycles go from taking years down to days or even hours. Approaches like Origin Trials help enable more experimentation but still require weeks or months for iterations. When you change the iteration rate of something, you fundamentally change the thing itself. 


Some fields like machine learning are advancing so fast that it is incredibly hard for standards-based approaches to keep up. By the time one design has gone through standardization and cross browser implementation, the field has moved on to something new which would have to go through the whole process again. 


That being said, standardization is still essential for many things (see disadvantages section below) and when feasible, standardizing should absolutely be attempted. 

Immediate support across browsers 

Because wasm is  supported across browsers, the functionality built on top of it will work across all browsers immediately as well. Interop and cross browser implementation of features is the biggest pain point for developers and by moving functionality to these lower level primitives, we’ll remove much of this concern. 

Improved security 

Because this functionality is built on top of incredibly hardened security sandboxes, there is substantially improved security compared to natively implemented APIs. Flash for example was removed from the web in large part because it was just too difficult to harden the complex plugin sufficiently, but now it can be run in WebAssembly, eliminating almost all security concerns. 

Disadvantages and limitations 

As with any new solution to complex problems, WebAssembly is not without disadvantages and limitations. Some of these are inherent and some have some promising solutions. 

This won’t replace JavaScript for most web development   

WebAssembly won’t replace JavaScript or make it obsolete, but rather extend its capabilities. 


WebAssembly in the browser is still entirely dependent on JavaScript and needs to interface through JavaScript to access other web functionality. Libraries and new functionality enabled by WebAssembly will be utilized through JavaScript APIs. While there are some proposals that could enable wasm to wasm module communication and direct interfacing with Web APIs, this is still in the early stages of development. 

Bundle size of pages

By moving more logic and functionality into userland, the size of pages will increase as well. This is a large problem as lower bundle size is the most important thing for a good user experience. As a result, developers should think carefully before ballooning their bundle size with this functionality, and it may be more relevant for larger web apps than smaller ecommerce or blog sites. This has long been an issue for JavaScript-heavy frameworks and is something where more solutions could be possible to improve the situation. 


Another potential mitigation here is to look at the popular functionality being shipped in userland and use that as an input about what functionality should be standardized to ship with the browser itself. By being battle-hardened in userland, browsers will have higher confidence and validation on what they should ship, dramatically simplifying the standards and implementation work. WebCodecs replacing wasm compiled FFMPEG or the handwriting recognition API to replace the wasm compiled option are perfect examples of this. 

Device capability access 

WebAssembly and other primitives are largely computation mechanisms and don't give any kind of root system access to the OS or device itself. Functionality like hardware access (USB or Bluetooth), screen or window management, input controls, file system, clipboard, and much more still require platform level APIs to access. Chromium’s Fugu project is specifically aiming to enable all of these cases for Chromium-based browsers, but implementations across other browsers would still be needed here. 

Conclusion 

WebAssembly is already enabling new functionality in the browser, but more than that it represents a fundamentally new approach to how functionality gets developed. The best way to improve a thing is to improve how you improve it and then basking in second order growth. As with any new paradigm there are advantages and disadvantages, but overall this is a powerful new approach for browsers and developers everywhere. I can’t wait to see what we all build together with it.



By Thomas Nattestad, Product Manager - WebAssembly
Labels:

About 14 years ago, Google Earth gave users a rush of excitement by allowing them to  zoom right in on their childhood homes. But that could happen only once they downloaded and installed the application. Earth was released as a native application because rendering the whole world in real time required advanced technologies that weren’t available in the browser. 
As the Web progressed, we wanted Earth to be available on the platform so it could reach as many people as possible and let them experience the entire world at their fingertips. Web apps offer a better user experience because they’re linkable, meaning you can share access to the whole experience with a single click; they’re secure, since users aren’t at risk of viruses that can come with software downloads; and they’re composable, meaning we can embed them in other parts of the web.
In WebAssembly (Wasm), the W3C web standard for bringing native code to the web, the Earth team found a solution to allow Google Earth to move across multiple browsers—something we’ve been working on for a while now. Earth first came to the Web about two years ago using Native Client (NaCl), a Chrome-only solution—at the time. It was the only way to run native code in the browser and offer the performance users expect in modern web applications. But cross-browser compatibility is not as easy as we would like, since not every browser supports new technologies the same way. 
Using WebAssembly, we see more possibilities not just for making apps more accessible across browsers, but smoothing out the online experience, as we’ve seen with Google Earth. You can check out the Earth preview beta to see what the Earth team has achieved and read about their technical implementation here.
How WebAssembly works with threaded applications
If you plan to work in WebAssembly, it’s important to understand some of the specifics, particularly around threading.
Some browsers offer multi-threading support and others don't. In the case of Google Earth, it is constantly streaming data to the browser, decompressing it and making it ready for rendering to the screen. Being able to do this work on a background thread has shown a clear improvement in the performance of Earth in the browser.
The Chromium-based browsers—including Chrome, the forthcoming version of Edge, and Opera—all offer support for WebAssembly (some with multi-threading, others without). Once the new version of Edge based on Chromium ships, apps in WebAssembly will work as well in Edge as they do in Chrome. Firefox offers good support for WebAssembly, but had to disable support for multi-threading due to a SharedArrayBuffer issue. And while Opera is based on Chromium, the current version of Opera only offers single-threaded support of WebAssembly. Safari has a strong implementation of WebAssembly, but it lacks full support for WebGL2. Our deep-dive technical post offers more details about WebAssembly support across the browsers.
Emscripten: The tool that enabled Earth to port to the browser
Taking an application that was originally created for native operating systems and bringing it to the web is no small task. The Emscripten toolchain helps developers compile their C++ into WebAssembly, also also emulates many of the OS interfaces that native applications use. For example, an application may use the POSIX API fopen which tells the OS to open a file. Emscripten sees this call and offers the correct behavior through browser technologies such as local storage.  It does the same thing for turning OpenGL calls into WebGL calls. Along with many other features, it dramatically eases the work of bringing a native app to the web.
Emscripten has been used to port other applications to the web, such as the 35-year-old AutoCAD codebase and more recent applications like Sketchup.
What’s coming next for WebAssembly
There are several features coming to WebAssembly in the future that Earth will use to improve the web experience:
SIMD support: SIMD (single instruction, multiple data) lets a single CPU instruction act on multiple pieces of data. When it’s set up in the right way, SIMD allows for high throughput of data processing. When the first set of SIMD support arrives later this year for WebAssembly, we hope it will dramatically improve Earth’s performance. 
Dynamic linking: This feature will give Earth the chance to optimize load time, and opens the door to embedding Earth in other web pages and online experiences. Currently, all modules that interact have to be compiled at the same time. With dynamic linking, you can break up an application into many modules and ship a very small client, then load all the other parts over time (known as lazy loading).
Better debugging: Today, Wasm supports source maps so that developers can see their source code in the developer tools. That’s a great first step, but we want to also allow developers to inspect variables and see proper stack traces.

Earth has now taken a major step by adopting a cross-browser standard that lets them bring the application to more browsers—with more improvements coming in the future. Consider trying out WebAssembly for yourself and your native code to reach all your users with a consistent, performant experience.


 Posted by Thomas Nattestad, Product Manager for Web Assembly, V8 and Web Capabilities
Labels: , , ,