Author: Ben James / Source: Hackaday
If you keep up with the field of web development, you may have heard of WebAssembly. A relatively new kid on the block, it was announced in 2015, and managed to garner standardised support from all major browsers by 2017 – an impressive feat. However, it’s only more recently that the developer community has started to catch up with adoption and support.
So, what is it? What use case is so compelling that causes such quick browser adoption? This post aims to explain the need for WebAssembly, a conceptual overview of the technical side, as well as a small hands-on example for context.
What is WebAssembly?
Javascript has been around since the 90s. To be honest, it’s done a pretty good job; whilst it certainly has its drawbacks, it’s succeeded at creating an interactive modern web, even escaping from the browser more recently.
But, inevitably, the type of applications being served up on the web today are far more demanding than could have been imagined when Javascript was first created. Computationally intensive applications and tasks like 3D graphics, video/music editing and VR/AR have traditionally only been able to run natively, because Javascript inherently doesn’t have the performance capabilities to support them.
But what if it were different? What if there was a way to run low-level, optimised code in the browser with near-native performance? That’s exactly the mission statement that WebAssembly aims to fulfill, and it’s a pretty compelling one.
All this talk can evoke grumblings from those who argue that intensive applications are still best off running natively. But ultimately, no-one can deny the convenience that web applications provide end users – no installation means no disk space eaten, no local security worries, and no installation process. It also provides a large amount of appeal to developers, who only need to deal with one platform. Code only needs to be written once, and is far easier to support and maintain.
WebAssembly was created with these high-level goals:
- Harness common hardware capabilities, be portable and efficient
- Produce modular binaries which use imports and exports in a similar way to Javascript objects
- Support non-browser embedding
- Integrate into the existing web platform (enforce the same security policies, access browser functionality through the same APIs available to Javascript etc)
Note: if you’re interested in reading more about the security of WebAssembly, the official docs provide a good overview, and [Lin Clark] has done a great deep dive on memory access.
How does it work?
Designed to operate at the lowest possible level without compilation for a specific platform, WebAssembly runs directly in the browser, and is the second ever language to be directly understood by browsers. This means that whilst it doesn’t produce machine code, it’s at a low enough level that the browser needs to do very little work to execute it.
WebAssembly comes in two flavours, the .wat text file, and the .wasm raw binary. The two are exactly equivalent and exist purely for convenience; binary code is shipped to the browser but text files are human-readable. Note that sending binary code to the browser instead of Javascript source files also has benefits for the page download size.
Whilst it’s perfectly possible to write WebAssembly yourself, you probably don’t need to, just like…
The post WebAssembly: What Is It And Why Should You Care? appeared first on FeedBox.