Is WebAssembly the Web GUI Future?

The desktop Graphical User Interface (GUI) has been with us since the 1990s, when Windows became mainstream. Out went character-based screens, replaced by icons and multiple fonts, selectable via mouse.

Around this time, the Web went mainstream. Unlike Windows and other desktop GUIs, however, the Web user experience was generally poor. Web GUIs had the odd popup window, lots of graphics and colored 3D buttons, and animated cursors… if you were lucky. At least in the beginning, websites were designed for displaying information, not sophisticated input.

(It didn’t help that, until 2000, producing nice-looking webpages required a lot of effort. You put controls, text and pictures into tables to give the page some structure. As browsers adopted new CSS standards, it became easier to have a website both look good and not vary in appearance between different browsers.)

If you want to create complex—and perhaps good-looking—GUI pop-up windows in your browser, your first choice of tool might be JavaScript. There are few alternatives; Adobe Flash is now history, of course, thanks to its failure to transition to mobile (not to mention the extensive security concerns related to plugins). But JavaScript is a bit of an arms race, with the potential to confuse developers: You have a choice of environments and frameworks such as Node.js, Meteor.js, React.js, Ember, and so on.

There is an alternative: WebAssembly, described by some as Adobe Flash without the plugins. A web standard that focuses on speed, it is meant to complement JavaScript, while also allowing web-based development in other languages.

WebAssembly isn’t the first attempt at speeding up web processes. Earlier experiments such as Google Native Client (no longer active) also did this; code written in C/C++ ran in a sandbox, isolated from the operating system. But that’s been discontinued in favor of WebAssembly.

Back in ye olden days of 2012, there was asm.js, a subset of JavaScript optimized for speed; it was successful up to a point, making it possible to convert C/C++ programs into asm.js that ran with notable speed improvements. Downloading and parsing asm.js applications, however, remained slow.

Producing WebAssembly is a two-part process on Windows, Linux or Mac; it involves compiling the application source, then running Emscripten to generate the Wasm (as WebAssembly code is called), JavaScript and HTML files. By having the Wasm code load as a binary image, WebAssembly improves on the download/parse time of asm.js, and the code itself runs about 5 percent faster.

We’re now seeing WebAssembly games every bit as good as those old Flash games that everybody used to play. For example, Funky Karts is a browser game written in C++/OpenGL ES 2 and WebAssembly. You can play the game instantly in your browser and read about its development.

In addition to games, WebAssembly has been used in statistical visualization, ray tracing, emulators, voice commands, and software development. It makes possible web GUIs that are almost as good as desktop GUIs.

Building the Better GUI

GUIs are made up of lots of controls, and you need to place them accurately and rapidly. WebAssembly lets your C/C++/Rust programs place lots of bytes on the screen very quickly, something that HTML and CSS were never intended to do (as they rely on the slower DOM (Document Object Model) to put controls on a webpage).

There are some great desktop GUIs available (both closed- and open-source) such as Qt and Nuklear. Many of these are written in C or C++, and are now being implemented on web with WebAssembly (for example, AssortedWidgets is written in C++ 11 with OpenGL ES 2, and has an impressive online demo).

But IMGui is way better. It’s used in many games, apps, and design tools, and there is now a WebAssembly implementation by the ImGUI author. As a complex web GUI, it is pretty feature-complete; plus, it loads in no time. If you need a web GUI, this is an excellent place to start.

Future Plans

The version of WebAssembly that all four major browsers currently support (Chrome, Firefox, Safari and Edge) reached MVP last year, but that’s only a starting point. According to Firefox’s Lin Clark, future features will include multithreading, SIMD support, and improved compilation. It will start compiling while still downloading, and then optimize running code to speed it up.

These features all help make powerful web GUIs possible by forcing WebAssembly programs to run faster. Multithreading will also make the GUI run smoother by allowing more intense computing tasks to be done in a non-GUI thread.


WebAssembly offers a way forward from the complexity that is current JavaScript development. Dart was originally intended to fill this space, but as a Google-only initiative, it was never going to work (and has been repurposed to drive mobile development with Flutter).

Developing the complex functionality that GUIs need is not a trivial task, and JavaScript is not the ideal language, as it has to work through the DOM. But thanks to WebAssembly, languages ordinarily used for desktop GUIs, such as C and C++, are utilized to build web GUIs.

Although C/C++, Go and Rust are the most popular WebAssembly development languages, other languages can also be used to develop complex web applications. According to the awesome page of WebAssembly (supported) languages, there are over 30 languages, though for many it’s still early days.

Nevertheless, I have seen a complex GUI work in a browser and I think that WebAssembly is the future, at least for now!

3 Responses to “Is WebAssembly the Web GUI Future?”

  1. StillDreaming1

    I’m really confused by this article, because the research I have done into WebAssembly up until now has told me the exact opposite. I was under the impression that GUIs were the only thing WebAssembly was bad for, which is what has held me back from taking WebAssembly seriously and has prevented me from learning/using it. I’m hoping that I am wrong because I really want WebAssembly to be successful and useful. I thought there was no way for WebAssembly to do actually display anything to the user without talking to JavaScript through some kind of API, and that every time you have to do this there is a major lag that you would not get if your entire program was in JavaScript, thus defeating the entire purpose of WebAssembly being faster.

    Am I wrong? Are there more direct ways for WebAssembly to provide a GUI?