The Internet

The web has always been a place for great minds to push the limits of what’s possible; what can be created; experienced. Born as an academic research project in 1969, the vehement determination of talented, passionate people pushing what it could do again and again — making scientific breakthroughs and history along the way — is why it is so incredibly ubiquitous in the modern world, used by over 5.03 billion people, that there are debates on whether it is a human right.

So, naturally, when something is said to be the next evolution of such a vast and intricate medium, capable of changing it entirely, well, suffice to say, that attaches some very heavy expectations.

NFTs, cryptocurrency and even the infamous Blockchain have held this promise, if only for a short while. Touted to be the Next Big Thing: Web 3.0. A rethinking of how data, the lifeblood of the internet, flows. That wave, has, for the most part subsided, leaving behind seemingly as many promises to change the internet forever, as horror stories about scams and hacks and even high-profile crimes.

Still, at its core, these are incredible, if esoteric, technologies, with real world benefits and impactful security advantages that do have real world applications; those applications just aren’t JPG Apes or Bitcoin, and while they may be beneficial, they certainly wouldn’t drive the medium forward, in any sense of the word. And that is what matters, in the end. Driving the medium forward, and evolving what experiences can be communicated. Because, quite frankly, these movements are born of, live for, and die to enrich, what they can make their users feel: connection. Wonder. Amazement. Joy.

But I digress. We’re here to talk about a different technology. Something that does exhibit the criteria demanded of technology that will leave its mark on the internet. But, to know where we’re headed, we need at-least a bit of an idea of where we are.

The Heralds of The Old New

Before around 2005, the web was a simpler place, comprised of little more than basic text documents, that at most pointed to each other, using hyperlinks. Web 1.0.

The interactive, participatory and easy to use web we know now, Web 2.0, on the other hand, is filled with sites that, for the most part, can be put into a spectrum going from static-ish sites (much like this one), to fully dynamic and interactive ones, such as, say, Facebook’s home feed.

And driving this period of transition, of looking at the internet fundamentally in a different way, is the beating heart of Web 2.0: web-app technology, which paved the way for one of the defining traits of Web 2.0: user-generated content and social media.

But what we’re interested in, is that first bit; what powered this transition, behind the scenes: the aforementioned web-app technology. A sort of Frankensteining of the core parts of a native, interactive and responsive app experience, traditionally found in installed software, onto the hisotrically static-er website paradigm that exists in browsers. The best of both worlds, offering the interactivity of an application, but the freedom of distribution, availability and accessibility of the internet, unbridled by restrictions and the occasionally predatory guidelines and rules of the app stores.

And while phrases such as “Web 2.0” represent slow gradual shifts in ideology and what people wanted, and what people could create, on the web, instead of hard, straight lines and a “software version update” that took us from one to the other, they serve to mark an important time: when public perception and public, change.

But still, no matter how you draw the line, or when, one thing is certain: we’ve left the humble text documents that started it all a long ways behind.

The Unwilling Participant

Powering this monumentous shift on the web, is the somewhat unwilling facilitator, Javascript. A simple scripting language made for trivial tasks and infamously written in 10 days (to be fair, no small achievement), that, over the past 25 years has been turned into an amalgamation of features and paradigms and obsolete (but never removed) behavior, hacked together to support modern-day requirements.

Like duct-taping a V8 onto a tricycle, (this is not hyperbole, this is a pun) Javascript has been extended and re-extended to be able to support all that is demanded of it now, while making sure it is 100% backwards compatible — a point of heated contention, as it gives rise to most of JS’s problems, done because you do not break the web.

But its limitations — missing features, messy semantics and subpar developer experience — coupled with a nightmarish ecosystem plagued by controversies and supply-chain-attacks (here, here and here just in the last few months) will only become more problematic, more encumbering, as time goes on.

Even the performance of Javascript, heavily accelerated and optimized for by state-of-the-art JS engines and JIT compilation optimizations, still can’t compare to native speeds (needed because that is what is expected of the web now). And then too, it comes relatively close because Javascript has decades of compiler iteration behind it.

There’s just no way to avoid the fact that Javascript is struggling to keep up with the exponentially increasing demands of the web, falling further and further behind each day.

Still vital, still used and still chosen to build new things. But not because it is a good option. And certainly not, because its the best. But because, it is the only one.

That is of-course, until now.

A New Contender

And that’s where the technology we’re gonna talk about, WebAssembly — WASM — comes in. A new standard, built with the goals of the modern web, but compatible and interoperable with all that came before.

WebAssembly is an official W3C standard, and recognized as the web’s 4th official programming language (after HTML, CSS and JavaScript), being backed by developers from Mozilla, Microsoft, Google, and Apple. The second universal programming language that all web browsers can understand and run, in the history of the internet.

It consists of a low level language similar to Assembly, that can be represented with text, then converted to an efficient, compact binary format (.wasm) that can run on all modern browsers.

It is very fast, running at near-native speeds and being capable of streamlining and off-loading heavy, performance-intensive tasks from the much slower Javascript, significantly increasing application responsiveness and performance in places. The compact, binary format it uses also means bundle sizes — an important metric used to estimate website load times, with smaller being better — become considerably smaller, allowing for faster site load times and a better user experience overall.

Magic

The magic of WebAssembly however, is not in any of this, as you’re not going to be writing scripts in WebAssembly yourself — it’s a low level assembly language, designed to be very close to compiled machine code, allowing it to also be very close to native performance. It’s magic comes from the fact that it is an easy compilation target. 

Now compilation is, simply put, an almost completely automated process that turns the code files on a developer’s computer into an executable file of machine code that a computer can easily run: a process that almost all programming languages have to go through, eventually. The output of compilation, however, can be many things. A .exe file for Windows devices, a .ipa file for iOS devices, .dmg for Macs or a plethora of other formats as well.

But now, you can compile to one more format: you can compile, to WebAssembly. And what this means in practice, is that JavaScript is no longer the only language you can run on the web. Web browsers can run any language now, if that language has a WebAssembly compiler. And this means that web-based programs can now be written in a growing list of languages, that includes C++, Python, Rust, C#, Go, and more.

Well Used Magic

While still quite new, and understandably rough around the edges, WASM is already a powerful, principled and practical approach to achieving high performance on the web, being used by big companies to build and ship production software.

AutoDesk, for example, was able to port their 35 year old C/C++ codebase over to WASM in a relatively short period of time, and Google could do the same with Google Earth; both of these render complex 3D models and environments, and both have gained significant performance improvements across the board, now running at near-native performance.

Figma, a very popular designing tool, also uses WASM, to deliver a high-performance C++ written designing experience that has native, buttery-smooth performance, and is available wherever there’s a browser.

Even performance intensive games are now nearly as easy to build for the web, as they are for any other device — with someone already porting over Doom, as expected —, as the Unity game engine can target WASM now.

WASM also has a good ecosystem, with powerful developer tools such as Emscripten, which can convert existing projects written in C, C++ or any other language that uses LLVM to WebAssembly, allowing them to become performant web-based experiences.

What all this means, in practice, is that now, complex, performance-intensive software is fully deliverable in the browser, cross-platform by default and with little in the way of performance overheads, while also providing a seamless experience with no installations required for the end user.

Not Just For The Web

Leaving web-development behind, WASM’s benefits are much more far-reaching, extending to various different branches of computing.

For one, its inherent cross-platform capabilities allow for simpler and safer ways to bring cloud-computing code, commonly written in a variety of languages, together. By providing a framework in which code can be written in any of a large (and growing!) list of supported languages, and then compiled to produce a common, simulated machine format, it allows components written in various languages—like Rust, Go and C++, to interact with each other.

Being secure by default, with each WebAssembly module executing within an isolated, sandboxed environment separate from the host runtime, and with restricted – but compatible — execution semantics, WASM can act also as a universal plugin format, allowing third-party components to interact with internal components in a custom system, letting you bring new components into a system while mitigating the risks that typically come with integrating them.

Tools such as WASI, which provides a way to run WebAssembly portably on any system using a standardized system interface, also allow for WASM to be perfectly poised as a viable way to run any kind of code, on any kind of system, in the near future.

And while WASM is undoubtedly faster overall, it doesn’t need ti have blazing-fast performance in every use-case, to be revolutionary. It just needs to work, not be slow, and support many languages. All of which it already does and is.

A Supplement, Not A Replacement

It is however important to realize that WASM isn’t meant to replace Javascript. At-least, not any time soon. What WASM does, is provide more options, unlocking a new way to create with the medium that is the internet.

For instance, our earlier example, Figma, uses WebAssembly to power its core design engine and editing tools. But the “shell” housing it, comprising its buttons and menus and graphics, is built using ReactJS, a Javascript framework: Javascript interoperability is a well supported, prominent feature of WASM!

However, despite its wide array of benefits, WebAssembly is not a fix-all solution: it will never replace HTML, CSS or the basics of JavaScript. What it is, is a tool that makes things previously very hard to do with Javascript, like building performance intensive applications on the web, much much easier, and greatly in the realm of possibility.

Web 3.0

When the web transitioned from being mostly read only, to interactive, from Web 1.0 to 2.0, so-to-speak, it was born of a shared love of technology, and led by people who had extreme passion and ingenious skill in their craft; it was a great leap forward, done because of the joy of leaping. It was a change in how we interacted with the web, and it was a fundamental shift in how the web interacted with us. It was born because of the promise of revolutionary new web-experiences, and it thrived, thrives, because it delivered.

It was the evolution of a medium, with people creating things on the web beyond others’ wildest expectations, all lead by passionate people who did so simply because they could. Because it was fun. Because the alternative was not doing it.

Such a paradigm shift, and the subsequent proliferation of previously unheard of web-experiences, is also the promise of WebAssembly, and one that it has already started delivering on.

And so, here we are, with WASM, a tool leading a fundamental shift in how developers and users think of the web as a platform, and that allows for nearly any app to be shipped to the web, capable of running anywhere there’s a browser. No installations, no revenue cuts to gargantuan corporations for deigning to allow your apps into their stores, no long wait times to ship updates and critical bug fixes.

The evolution of a medium, making new things possible, and empowering everyone to create in previously unimaginable ways, and leaving just you, the experience you coded, and the ability to share it with the world.

Now that, sounds like Web 3.0.