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