In Tech, we are constantly in a game of ‘catch-up’. Rapidly developing technologies seem to pop up out of the ether whenever you’re not looking. In addition, startups keep moving the goalposts on what it means to be agile so it’s very easy to feel as if you will never catch up. Advancements in cloud services (AWS, Azure, Firebase), CMS (Drupal, Wordpress, Joomla), and low-code solutions (Squarespace, Retool, Zapier) have redefined the landscape.
One of the most notable improvements is in front-end web development. Front-end web development used to be a joke in terms of technical skills required (even though CSS styling is a headache and a half). HTML and CSS aren’t even technically programming languages. However, with the transition to the cloud, the importance of web development is front and center.
IaaS, PaaS, and SaaS companies are keeping the technologies they leverage online. The drawback to having your entire code stack on the web is that HTML and CSS (even JavaScript) don’t usually cut it. Breakthroughs such as Typescript, Angular, React Native, Vue.js, and several other web technologies have redefined web development and what it means to be in the industry. One particular breakthrough is WebAssembly (a.k.a. WASM). Since Java, Flash, and Silverlight support is being removed from modern browsers, WebAssembly is the only alternative to JavaScript for running code in the browser. In addition, when it comes to computationally intensive tasks, WebAssembly knocks JavaScript out of the water.
WebAssembly (abbreviated WASM) is a binary instruction format for a stack-based machine. WASM is designed with high-level languages such as C/C++/Rust (for the uninitiated, Rust is essentially C++ with better safeguards for memory while maintaining high performance) in mind. Although WebAssembly can be written by “hand”, it was created with the intention of being able to be used as a portable target for compilation.
As you can see above, WebAssembly interacts with the browser. Native code is compiled into a WASM file which can then be called through JavaScript on the front-end. There are many advantages to this. First and foremost, WebAssembly is a low-level language. This means that programs developed in it are faster and more memory efficient. As such, functions originally written in JS can be re-written in C/C++/Rust, compiled to WASM, and called on the front-end. Naturally, native client and server internal applications can be re-compiled to WebAssembly lowering the barrier for entry if you have existing software you want available on the web.
First and foremost, the biggest impact of WebAssembly is the ease it gives companies to port software to the web. Having the ability to increase performance by writing functions in a popular, already known language such as C/C++/Rust is convenient. That said, where WASM truly shines is in re-defining what we thought feasible in web deployment. Some use cases include uses in image and video editing, peer-to-peer applications, live video augmentation, scientific visualization and simulation, CAD applications, VPN, and remote desktops. Now before you run to the races and start overhauling everything to WASM, there are a few things to consider.
WASM 1.0 launched with compatibility for four browsers, namely, Firefox, Chrome, Safari, and Edge. The drawback here is that WASM won’t work on Internet Explorer. Thankfully, IE is on its last breaths so concern shouldn’t be too high. I’m sure your target market would never use Internet Explorer, right?
It is important to show exactly how WebAssembly performs at computationally intensive tasks. Below, you’ll find a benchmark test between JS and WASM. This particular test runs 10 iterations of a recursive Fibonacci function. As you can see, the JS and C++ code is nearly identical. Since the C++ function is compiled to WebAssembly, the function makes better use of the device’s architecture, increasing performance by a significant factor. As you can see, when it comes to speed, WASM takes only a ⅓ of the time. GitHub user Takahirox has further JS vs. WASM tests available if you’re interested.
There are several security advantages to WebAssembly. One of the key advantages of WebAssembly is code obfuscation. Since WebAssembly is compiled C/C++/Rust code, the final product is very different, allowing you to give your source code a layer of protection. The compiled fib function in the previous section is available for comparison if you want to see what C code looks like compared to WASM (do keep in mind that the WASM displayed is in readable format, not in the binary it’s usually displayed as).
In addition, WASM modules require that all functions and their associated types are declared at load time, even when dynamic linking is used. This feature subtly establishes a structured control-flow, protecting WebAssembly programs from control-flow hijacking attacks.
Compared to traditional C/C++ programs, WebAssembly semantics remove certain classes of memory-safety bugs. Local and global variables stored in index space are fixed-size and addressed by index. Data stored in linear memory can overwrite adjacent objects which you would think is a concern, but since WebAssembly has that structured control-flow as well as protected call stacks, mitigators such as data execution prevention (DEP), and stack smashing protection (SSP) are not needed since direct code injection attacks are prevented.
All that said, I highly recommend you read “Security Chasms of WASM” by the NCCGroup. It’s important to understand that exploits do exist if you do not protect your environment correctly.
The uses for WebAssembly are vast. If you’d like to find out how to get started, you can navigate to WebAssembly’s ‘getting started’ page. Alternatively, if you need help deciding how WebAssembly fits into your environment, contact us, and we’ll be glad to help.