• Home
  • Blog
  • WebAssembly – power hidden in browser


WebAssembly – power hidden in browser

31.05.2019 - Read in 6 min.

Did you know that WebAssembly is used in the development of blockchain applications? Or that despite its young age, on numerous levels it beats JavaScript and asm.js in terms of performance?


Did you know that WebAssembly is used in the development of blockchain applications? Or that despite its young age, on numerous levels it beats JavaScript and asm.js in terms of performance? Do you realise that your apps written in C or C++ can be used in web browsers? With no need to rewrite them to JavaScript? Do you know that an app2, the code of which has been developed for the last 30 years, has already done that thanks to WASM?
Or maybe you’ve been thinking about sharing your game, created in Unity
or Unreal Engine, to a broader audience through web browsers?

A bit of history…

JavaScript was created in 1995 by Brendan Eich, at that moment with Netscape. It’s a monopoly in the category of programming languages supported by web browsers. JavaScript has gone an incredible way to become the language we all know today. Engines like Chrome V8 perform miracles in the area of just-in-time compilation (JIT), but JavaScript still struggles to achieve native performance in web apps. In 2013, Mozilla released asm.js, i.e. a JavaScript subset comprising a minimalistic set of functionalities (e.g. it does not contain the “for” loop). It ensured higher performance thanks to compilation of an app before it was run, and static typing.

The need for performance

Recent years have brought us many technologies that develop at an astonishing pace. Trends among users suggest a growing need for mobility and “constant availability” of favourite platforms and apps. In 2016, the number of users connecting to the Internet with the use of mobile devices exceeded the number of those using PCs. Accessing apps only at home, from a PC, becomes a thing of the past. Excel or Word documents can now be edited online. Browsers have become a kind of an operating system. The world moves online, but to make it possible, performance is a must. Addressing the needs of users and developers, in March 2017 W3C released WebAssembly (WASM) – second ever programming language (apart from JavaScript) and first binary language supported by web browsers.

Native performance for everybody

I’m sure we all remember Adobe Flash, Java applets, or not-so-distant PNaCL

(Portable Native Client), i.e. attempts to take over the Internet by a technology other than JavaScript. What differentiates WebAssembly from the above-mentioned technologies is the fact that WASM is embedded in browsers just like JavaScript, and it’s officially a part of the web standard resealed by W3C. Flash and Java applets relied on plug-ins, and they were never an integral part of browsers, but just an artificially “attached” creations. On the other hand, PNaCL is only available in Chrome. For over a year, Google has been working to move Google Earth from PNaCL to WebAssembly, which will increase the performance and above all will allow users to access this product from any browser.

This opens a whole new perspective to companies that have been creating apps limited by a particular environment they were intended for.

How Autodesk used WebAssembly

An excellent example of using WebAssembly is Autodesk, who has been trying multiple times to introduce its flagship product Autocad in a web browser. There were numerous attempts – Flash, HTML5+JavaScript. Due to the costs of moving the entire code for such a large product like Autocad, and the performance needed to ensure fluent operation in a browser, the Autodesk team kept failing. At the moment, the web version of Autocad uses its own engine written in C++. Recompiled to WebAssembly, and thus eliminates the unknown, i.e. the potential performance of the app rewritten to JavaScript. This lack of predictability of JavaScript is presented on the diagram below.​4

Apart from higher performance of WebAssembly, the diagram depicts deviations occurring with each subsequent execution of the code.

Efficiency of finding exceptions in the source code map was tested (using a browser tool for code debugging significantly speeding-up the work of the developer).

Another important aspect is the cost. WebAssembly enables the use of an already written code, which can be recompiled in such a way to make it understandable to browsers.

Autodesk is not an exception

Other examples of large realisations with the use of WASM are Figma
– an app for designing interfaces simultaneously on various devices, and PSPDFKit, an app for generating PDF documents. I have described their experiences with WebAssembly in the context of benchmarks.

Graphic designers and computer game developers should be interested in
the fact that both
Unreal Engine and Unity Engine are compiled to WASM.
An example of a
game written in Unity that can be played in a browser.

The idea behind WebAssembly reaches beyond porting of apps written in low-level languages for browsers. Just take a look at Nebulet – an OS project with WebAssembly modules and WASM to machine code compiler. Therefore, we can expect that WASM will not only be a permanent part of browsers. It will be also a native component on various devices, which will open new possibilities e.g. for IoT (Internet of Things).


A few of the abovementioned companies decided to describe their experiences with WebAssembly and measure the increase in performance after moving to

WASM. The results shared by Figma speak volumes.5

Loading a large project in a browser app took over 3 times less in WASM in comparison to compiling it to its predecessor. On their blog, PSPDFKit have also shared benchmark results for their engine comprising 500.000 lines of code in C++, which is run in a browser thanks to WASM.

The charts above show that even though there’s still a long way to go for developers responsible for WASM support in browsers, the possibilities offered by the language are clearly visible. Over two times better result of WASM

(Firefox 61) in comparison with the best result of JavaScript (Chrome 67) is
a great achievement.

This does not mean that JavaScript will be forgotten along with the spread of WASM. It is still an efficient language that enables fast generation of code and works perfectly well in manipulating DOM trees. WebAssembly complements JavaScript in areas where raw computing power is needed. None of the above-mentioned companies has dropped JS, and instead they built their UIs using JavaScript/Typescript.

A promising technology, but…

WebAssembly is a very young technology, and the programmers behind this project have still a lot of work to do.

At this moment, Rust, C, and C++ languages are the easiest to compile to WebAssembly. They all have one major feature in common – manual memory management.

WebAssembly still works to add a garbage collector or threading. It would naturally make it easier to compile the most popular languages used in major corporations, i.e. Java and C#. Obviously, compilers are already available (TeaVM or JWebAssembly for Java, Blazor for C#), but their capabilities are currently limited.

Another issue is WASM access to the DOM tree. This functionality still requires the use of JavaScript code, but the creators are working to make it happen (read more). Of course, there is no obstacle to move a demanding logic to WASM even now, and use JavaScript for DOM tree manipulation and visual presentation, as it still remains number one in this field.

Fortunately, WASM and JavaScript perfectly complement one another, and JS environment enables easy integration of WebAssembly modules. The most popular bundlers, such as Webpack or Parcel, support WASM (Webpack from v.4, Parcel from v1.5). Naturally, JavaScript purists who would like to use WebAssembly, are not stuck with bundlers, as they can reach for a natively shared WebAssembly namespace, which enables synchronous and asynchronous import of WASM modules.

To sum up, milestones in the development of WASM will be:

  • Garbage Collector

  • Direct access to Brower API and DOM tree

Is it worth it?

WebAssembly is already supported by Golang – a language developed by Google. This is important because since Q1 2018, Portable Native Client is
no longer developed (contrary to WASM).

Microsoft also sees the potential of this language, which is why they took the C# compiler created for WebAssembly – Blazor – under their wings.

Browser support is also promising:​7

Over 75% of all users can already use WebAssembly, and if a browser does not support WASM code. A compiler can be configured to create code in
a version supported by WASM’s predecessor – asm.js.

In my opinion, all of this suggests that the world needs WebAssembly and aims at making it a part of the Web Development canon as quickly as possible. We are given a tool that offers huge opportunities. Personally I can’t wait for a major project that will use WebAssembly as its primary solution.
Now, with blockchain and machine learning looming on the horizon, I don’t think I’ll wait long.

  1. https://polkadot.network/#whatisit

  2. https://web.autocad.com/

  3. https://www.youtube.com/watch?v=TwuIRcpeUWE

4. https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webass embly/

  1. https://blog.figma.com/webassembly-cut-figmas-load-time-by-3x-76f3f2395164

  2. https://pspdfkit.com/blog/2018/a-real-world-webassembly-benchmark/

(JavaScript fallback is a result of asm.js code)

  1. https://caniuse.com/#feat=wasm

Article notes


Mariusz Miszuta-RST Software

Mariusz Miszuta

Full Stack Developer

He works as a front-end developer. He’s an experienced JavaScript / PHP developer in the areas of e-learning and transport. He works with React.js, Redux, Node.js, Symfony, Docker, Ansible and Puppet. After hours, he looks for a way to make a good use of VR in medicine, he likes good coffee, and he plays the ukulele.



Thank you!
Your email has been sent.

Our website uses cookies to work correctly. Using this website with current settings means that cookies will be stored in the browser’s memory. Cookies settings can be changed in the browser’s options. For more information please visit Cookies policy.