WebAssembly and the Wizards of Hogwarts

There is a new kind in the web development hood: WebAssembly. It is fast, portable, supported by the big players and should allow making the world wide web the biggest software platform in existence. It doesn’t matter if you are an experienced software architect or a front-end developer — everyone will be able to profit from WebAssembly’s existence.

In this article, we will look at what WebAssembly is, how it works and how it works alongside its sibling JavaScript.

1. Introduction

On the 17th of June 2015, Brendan Eich — the inventor of JavaScript — and the teams behind Mozilla, Chromium, Edge and WebKit presented a new browser standard: WebAssembly, a portable and highly efficient byte-code compilation target for high-level languages such as C++ and Rust (Eich, 2015).

However, what does this mean? What is the reason that WebAssembly should exist in the first place? Should JavaScript developers be worried now? And what do the wizards of Hogwarts have to do with it?

2. Web Development Back Then

Back in the day when you could call yourself web developer because you only understood HTML, web development itself was a rather interactionless and static field of business. Netscape Communications, one of the establishing companies who built the world wide web as we know it today, soon realised that websites lacked to be interactive and dynamic (Cassel, 2018). They wanted the web to be a new form of a distributed operating system rather than just a simple HTML document-accessing application on your computer.

Marc Andreessen, who was the founder of Netscape Communications, proposed that HTML needed some kind of “scripting language” that was approachable — something you could glue directly into the markup. A language that is easy to use by newbie programmers who didn’t want to handle compiler errors or strictly-typed syntax.

That was the reason they hired the experienced programming language and network code developer Brendan Eich. Brendan’s first task was the nearly unachievable goal of creating such a scripting language for the web — due in 10 days. They (later) called it: JavaScript (Severance, 2012).

3. JavaScript’s Destiny

I don’t need to dig too deep into the history of the web to show you one crucial pain point of today’s web technology standards: JavaScript is a scripting language for the browser to interpret. I repeat it:?JavaScript is a scripting language for the browser to interpret?— not some fancy multi-paradigm system programming language that focuses on speed, security or code maintainability. It was supposed and designed to be an easy-to-understand dynamically-typed scripting language to give your website some cool DOM manipulations and decorative animations. Nevertheless, see what happened:

“Any application that can be written in JavaScript, will eventually be written in JavaScript.”

A quote by Jeff Atwood (co-founder of Stack Exchange) that is popularly referred to as Atwood’s Law (Atwood, 2007). Ever since frameworks like NodeJS or React Native became widely used, JavaScript’s possibilities already crossed the border of just living on the client-side inside of a browser. It’s nearly everywhere.

Also, NodeJS’ NPM package manager is currently the most prominent and most active package registry platform ever created. As an example: From May 10th to May 17th of 2018, JavaScript developers downloaded 5.2 billion NodeJS packages from the NPM registry, setting a new record (npm Inc., 2018).

4. Treacherous Atwood’s Law

There are thousands of courses, books and tutorials on how to learn JavaScript. Every computer-related school now or then teaches JavaScript. Nearly everyone could be able to learn it anywhere with a minimum amount of effort. If you search for “Learn JavaScript” on Google, you’ll get 2’220’000’000 search results. In comparison: When you search “Learn Java” you’ll get 305’000’000 results.

Though, is that a good thing? Is an originally lightweight scripting language capable of ruling the world of computational web development? My opinion: No, it’s not, and I believe there won’t be such a bright future for JavaScript as nearly everybody claims. Let me explain it with a Harry Potter analogy:

5. Muggles Entering Hogwarts

Do you know how it feels to watch front-end developers call themselves “full-stack software developer” after they’ve simply learned NodeJS? It feels like Muggles entering Hogwarts—a school full of wizards. Only that in our case these wizards are trained software engineers and computer scientists. These are the people who learn all the hardcore-implemented algorithms and compilers, programming languages and operating systems. They know precisely how to build software (Might, 2011).

Do front-end developers know how to write actual software? I’d say we better don’t talk about it.

Muggles aren’t invited to Hogwarts because they have no magical ability. Front-end developers weren’t “invited” for software engineering too because they couldn’t even do something with the languages they knew. Nevertheless, now — thanks to all the cross-platform JavaScript runtimes — they’re suddenly here to do some magic. But imagine, what if the wizards of Hogwarts, our beloved software engineers and computer scientists, would be able to perform magic in the real world — or our case: the front-end? What would happen? What could go wrong?

6. WebAssembly Says Hello World

WebAssembly is the new player in the web development industry. It’s fast, small, non-readable and not even a real programming language. Yes, you heard that right. You literally can’t code in WebAssembly (Rourke, 2018). So I may hear you asking: Why should we all be excited about it? Well, as mentioned earlier, it’s a compilation byte-format target for high-level languages. You write your code in such a high-level language like C or C++ and compile it down to WebAssembly. The magic trick: It works in the browser, and it’s super fast — sometimes about 5 to 20 times faster than JavaScript (Aboukhalil, 2019).

7. WebAssembly in a Nutshell

Enough with the marketing fuzz. The real face behind the term “WebAssembly” isn’t that uniform as it’s being marketed. WebAssembly itself is only a piece of a bigger technology chain of workflows and concepts. There are several other key components that are important for delivering super-fast web applications. It’s also good to know what its current limitations are and for which use cases it’s the best. But first, let me introduce you to the five key components:

7.1 WAT — WebAssembly Text Format

This is a human-readable file format you’ll get when you compile your C, C++ or Rust code. It represents the abstract syntax tree (AST) from the source code of a programming language. An AST — or in the WebAssembly case: a?.wat file — may be verbose, but it does an excellent job at describing the components of source code. Representing source code in an AST makes verification and compilation simple and efficient. Here is a simple return function called getDoubleNumber written in C:

If you compile this C code, it will return a?.wat file which contains the abstract syntax tree of our getDoubleNumber function. It looks like this:

7.2 WASM — WebAssembly Binary Instruction Format

While being in production, you probably won’t send the text instruction format file to the client-side. You’ll only send the binary instruction format (.wasm). This is the actual low-byte format file, written in non-readable hexadecimal code. Usually, they’re referenced as WebAssembly modules (Mozilla Foundation, 2019). Here is the example from the getDoubleNumber C function from above:

7.3 WASM Module Instantiating

If you want to access the C code within your website, you need to instantiate the WebAssembly?.wat module inside of JavaScript. This would look like this:

7.4 WebAssembly Compilation

In order to get a?.wasm or?.wat file, you first need to compile your source code. There are already different compilers for the various languages out there. The most common one — and also the most famous one — is called: Emscripten. Emscripten is described as a so-called LLVM source-to-source compiler with the main focus of compiling C code straight to a subset of JavaScript known as asm.js. However, the recent rise of WebAssembly has pushed the team behind Emscripten to shift its focus to help making WebAssembly more accessible and easier to get started with. You can then access the Emscripten compiler inside of your command-line interface to easily compile selected source code.

7.5 Original Source Code

To write efficient software and compile it to WebAssembly, you need to be proficient in C, C++ or the rather new Rust programming language. The WebAssembly Working Group has its plans to add more languages in the near future. But, right now they have other priorities and next steps on their roadmap. They especially focus on the biggest pain points of WebAssembly.

8. Pain Points And Limitations

The WebAssembly workflow sounds too good to be true, doesn’t it? Just write your code in a high-level language, compile it via Emscripten and then instantiate it inside of JavaScript — easy as that. Well no, it isn’t. There are still some huge pain points for easily porting your desktop-like application to the web, despite not having a garbage collector or exception handlers (WebAssembly Working Group, 2019). The biggest pain point right now is for sure the lack of web APIs. Let me give you a simple use case: Let’s say you want C++ code that can listen if a user clicks on a button and then render some data from your database into the client-side DOM view.

Well, I need to disappoint you, this isn’t going to work because WebAssembly can’t access the DOM API. The only way to access it is via JavaScript. If you would want to develop actual WebAssembly-ready client-side software, you would need to write some kind of JavaScript glue code (Mihaylov, 2018), that acts as the asynchronous bridge between your WASM module and the client-side HTML page.

9. Current Best Use Case

Currently, the best use case for WebAssembly under these circumstances would only be math-heavy calculations for graphics rendering inside of an HTML5 canvas element. This is because the canvas element is the only place where you can create a graphical user interface without accessing the DOM. This doesn’t sound very interesting for lots of people, but at least it’s super promising for the gaming industry. Since games rely on heavy shader calculations and simulations, the compilation to WebAssembly into a canvas makes perfect sense. That’s why Epic Games showcased a compiled Unreal Engine C++ high-resolution game inside the browser. Everything related to high-fidelity graphics or simulations is the easiest fit for WebAssembly right now — but for everything else that still needs to access or manipulate the DOM: use a glue code mixture between WebAssembly and JavaScript.

10. Glue Code

But Wait, this sounds familiar? Glue code? Wasn’t this the original purpose of JavaScript? Well, yes, it was. However, since the WebAssembly Working Group is actively working on an official DOM API (Mozilla Foundation, 2019), what’s the main purpose of JavaScript in the first place, though? If we soon can create very efficient full-stack web applications with just one high-level language, do we really need JavaScript in the near future?

Well, we don’t know, you can’t kill a whole ecosystem with millions of developers overnight. This didn’t work for PHP and also won’t work for JavaScript. However, different people have different predictions. Moreover, here is my prediction for the future:

11. WebAssembly’s Future

Since people with in-depth knowledge of software development and computer science—aka our Wizards from Hogwarts — soon have the ability to port their power to the client-side, we will most likely see a completely new age of the world wide web as we know it today. Netscape Communications’ original vision of the web as a distributed operating system could finally become a reality. Native apps, as well as their app stores, are going extinct and whole software packages like the suites from Adobe and Autodesk will entirely run inside the browser. The web will push its current borders far beyond what we now define as the epicentre for the information and entertainment industry.

In the near future, JavaScript will still be an essential role, but not as important as it is today. It will act as a simple scripting language to provide your website with some dynamic content and to create some cool animations.

The positioning of JavaScript will most likely be like the one it originally was being created for, and WebAssembly will act as the binary format for the browser to do all software-like heavy-lifting.

But, despite all of these predictions, there are some pioneers who created some real-life use cases with WebAssembly:

12. Real-Life Use Cases of WebAssembly

12.1 Figma — a Browser-Based Interface Design Tool

They’ve written Figma initially in C++ and were using a cross-compiler from C++ to asm.js (one of WebAssembly’s predecessor). After the notable adoption of WebAssembly in all major browsers, they took the chance to switch. The loading time for opening design documents improved by more than three times.

12.2 Autodesk AutoCAD — CAD Drawing Software

The original codebase for AutoCAD, which is older than the world wide web itself, has been compiled to WebAssembly and put onto the internet as a web app.

12.3 eBay — Barcode Scanner

The team behind eBay wrote an early version of a JavaScript barcode scanner two years ago — but it worked only 20% of the time. They’ve rebuilt it completely in C++, compiled it to WebAssembly, wrote some glue code in-between the .wasm modules and made it a working thing.

Bibliography

Aboukhalil, R. (2019) “How We Used WebAssembly To Speed Up Our Web App By 20X (Case Study)”?Smashing Magazine?[online] Available at?https://www.smashingmagazine.com/2019/04/webassembly-speed-web-app ?(Accessed 08.02.2021)

Atwood, J. (2007) “The Principle of Least Power”?Coding Horror?[online] Available at?https://blog.codinghorror.com/the-principle-of-least-power ?(Accessed 08.02.2021)

Cassel, D. (2018) “Brendan Eich on Creating JavaScript in 10 Days, and What He’d Do Differently Today”?The New Stack?[online] Available at?https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today ?(Accessed 08.02.2021)

Eich, B. (2015) “From ASM.JS to WebAssembly”?Brendan Eich Blog?[online] Available at?https://brendaneich.com/2015/06/from-asm-js-to-webassembly ?(Accessed 08.02.2021)

Might, M. (2011) “What every computer science major should know”?Matt Might Blog?[online] Available at?https://matt.might.net/articles/what-cs-majors-should-know ?(Accessed 08.02.2021)

Mihaylov, B. (2018) “How WebAssembly influences existing JavaScript frameworks”?Boyan Mihaylov Blog?[online] Available at?https://boyan.io/how-webassembly-influences-existing-javascript-frameworks ?(Accessed 08.02.2021)

Mozilla Foundation (2019) “WebAssembly.Module”?MDN JavaScript?[online] Available at?https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Module ?(Accessed 08.02.2021)

Mozilla Foundation (2019) “What is WebAssembly?”?MDN WebAssembly?[online] Available at?https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts ?(Accessed 08.02.2021)

npm Inc. (2018) “How well do you know your npm trivia?”?Jaxcenter?[online] Available at?https://jaxenter.com/npm-trivia-144846.html ?(Accessed 08.02.2021)

Rourke, M. (2018) “Learn WebAssembly: Build Web Applications with Native Performance Using Wasm and C/C++” Birmingham:?Packt Publishing, p. 32

Severance, C. (2012) “JavaScript: Designing a Language in 10 Days”?Computer 45?(2), p. 7–8, DOI: 10.1109/MC.2012.57, Print ISSN: 0018–9162, Electronic ISSN: 1558–0814

WebAssembly Working Group (2019) “Features to add after the MVP”?WebAssembly Roadmap?[online] Available at?https://webassembly.org/roadmap ?(Accessed 08.02.2021)