🕑 Estimated reading time: 8mn
By Horacio Gonzalez, Dev Rel @ OVH
WASM is a binary portable format serving as a compilation target for many other languages. The result of the compilation can be used inside the VMs of modern web browsers and Node.JS. It is fair to say that WASM is a spiritual successor to Java applets, Flash and Silverlight but open source, standard and natively supported by web browsers! In terms of performance, WASM is fast, memory-safe, efficient, sandboxed, debuggable and is part of the Web toolkit. Again, WASM does not replace the web stack, rather it completes it.
Many companies and applications use WASM today, including Figma, Autocad, Qt, Unreal Engine, Unity, Google Earth, etc. The common denominator between all of these is that they have strong requirements in terms of performance and memory usage.
If you wish to try out WASM, you can do so in WebAssembly Explorer or its refreshed version WebAssembly Studio. You can also use the local toolkit
emcc to compile your WASM code on your machine or on your CI. The name reflects
gcc applied to Emscripten. You might want to start a web server to serve your files on localhost as well; some browsers content security policies might prevent you from retrieving content from the file system directly. This will avoid the issue.
Writing WebAssembly code follows this process:
WebAssembly typically relies on a stack memory and its functions always return what is at the top of the stack at the end of their execution. There is only one specification but the implementation is up to the browser vendor, which might very well decide not to use a stack as the driver data structure. If you are on a Windows installation, it is recommended you use the Linux subsystem for Windows to develop with the toolkit.
WASM has its own package manager, WAPM, where you will find all sorts of packages that will complement your applications and allow you to iterate much faster on your development. With Wasmer, the technology gets out of the browser and can reach your OS! Using both of these ideas, you can create applications that will rely on standard packages that you can even compile yourself to create rich and performant applications. Squoosh, the image compressor, is a perfect example of that, since it embarks several image compression algorithms in a single web application and is very performant.
Although the present form of WebAssembly is very promising, its future shines brighter. The current multi-threading capabilities of the technology are seen as a hack based on shared workers. Soon, this mechanism will be a first-class citizen, along with SIMD, or Single Instruction, Multiple Data, which is a way to highly parallelize similar operations using the features of current generation hardware. Speaking of hardware, there is an ongoing effort to standardize access to system interfaces with WASI, which gives access to sockets, file systems, random number generators, and more. And to increase the visibility, accessibility and comfort of using WebAssembly, Garbage collection and Exception handling is on the way and will help bringing Java into the ecosystem in the vicinity of 2020! And if you are more of a C#/.NET person, you might want to check out Blazor as well.
How do Native modules compare to WebAssembly?
Native modules have an additional compilation step. With WebAssembly, there is no need for additional compilation as it is natively supported by the browser.
You certainly can but the performance will not be better. It is more relevant to rewrite your code using AssemblyScript, for instance.
What about security?
Unfortunately, this technology opens new attack vectors that can use the performance of WebAssembly such as cryptominers or simply keyloggers. A bug in the original language or dependencies may be transferred to WebAssembly.