WebAssembly

WebAssembly is amazing, even with its MVP version it has already opened new avenues for what is possible on the web in terms of performance, portability and security. In this article I will talk about WebAssembly and what makes it so revolutionary but I will also walk you through some of the use cases where WebAssembly, at least in its current version, would not function as fast.

So far Javascript has been the only language that you could use to write logic on the web. But when Javascript was first designed in 1995, it was not designed to be fast. It was rather designed to be easy for the developers to quickly prototype something and test it on the browser. That is because of some of the features in Javascript including dynamic typing. In Javascript you don’t need to specify the type of your variables, the first time you assign a value to it, the Javascript Engine would detect the type automatically. You don’t even have to stick to the same type, so later in your code you can start assigning a different type to your variable. This is obviously very easy for the developers, but not so easy for the Javascript Engine to optimize the performance.

So Javascript was slow till 2008, when the engines started to become more competitive. Just in Time (JIT) compilation was one of the main drivers of this increase in performance.

Let’s review what JIT means in its name: interpreters and compilers and two ways of translating a human level language (C++/Javascript) to a machine language (Assembly).

Interpreters make the translation line by line and as the code is being executed, but compilers take their time ahead of time and make a more optimized translation. So Just in Time compilation literally means, make a more optimized translation through compilers, but doing that in time and as the code is being executed.

So with JIT, Javascript Engine watchs the code as its being executed and marks the pieces/functions that are being called more frequently as warm. The engine then creates a compiled version of this piece/function, something that takes longer to generate but is faster to execute. When the engine finds functions that are really hot, it generates an even more optimized version of the machine code.

What WebAssembly does, is that it takes a statically typed, low level language like C/C++/Rust and compiles the code ahead of time. So you ship a .wasm file which is an assembly like format to the browser. Your browser doesn’t need to go through all the hassles explained above, it just executes the .wasm file.

But to be precise, WebAssembly is not a physical machine code, it is rather a conceptual machine code. And that is a deliberate design decision to gain portability. So you actually compile your code to an intermediate representation (IR), and every browser does the last step of translation from IR to the physical machine code locally. But wasm instructions are designed in a way that makes this last piece of translation very fast.

Another interesting feature of WebAssembly is that it is executed in the same sandboxing environment that Javascript is executed in, and it follows all the security models of the web. Because it is an assembly like language it doesn’t mean that it has more access to the underlying operating system. You don’t have any extra permissions to what is possible in Javascript. Also you cannot mutate the .wasm file after it is been delivered to the browser.

So far we learned why and how WebAssembly becomes performant, portable and secure and this already opens a lot of opportunities to build more complicated products on the web.  But there is another aspect of WebAssembly that also makes me excited and it is that you can take advantage of all the code you have built in C/C++ and just ship it to the browser.

For 30-40 years we have builts a lot of complicated products for the desktop, so we have huge set of vetted code that has been used and tested for many years. If it wasn’t for WebAssembly we would have to write the whole code base in Javascript to deliver the same functionality on the web. This is a huge save in cost/time.

There are also a lot of amazing developers with many years of experience in building secure and scalable code in C/C++ and we can start using this pool of talent on the web!

A lot of companies have already started doing so. A famous example is AutoDesk, that has started moving a version of AutoCad to the web. AutoCad was first released in 1980s and it is an essential software for designers and architects. Being able to use the same code base and deliver the product on the web has been a huge win for AutoDesk.

WebAssembly is in its MVP version right now. The potentials are huge and the team is working to expand the features. But in its current version, there are a few things you cannot do with WebAssembly:

1- WebAssembly doesn’t support garbage collection (GC). So right now, you need to manage your own memory in C/C++ code, but GC support is on its way, and could be released in the future versions.

2- WebAssembly doesn’t support multi-threading right now, it is one of the first features to be released. Firefox even released this shortly but had to take it back because of the security issues in the SharedArrayBuffers.

3- WebAssembly doesn’t have access to the web apis. So everytime you need to make a call to an api you need to call back to Javascript, make your call and come back to WebAssembly. There is a cost associated with this switch between JS and Wasm, so if you need a lot of access to Web apis from your code, you probably want to wait.

I am hoping that we can start taking advantage of WebAssembly in our current product as well as our future architecture designs.

If you want to learn more about WebAssembly I suggest following Lin Clark on her twitter/Mozilla hack account. She is an amazing engineer and educator and has a lot of talks and articles about this topic.

Post Your Comments

Your email address will not be published. Required fields are marked *