The Fourth Language of The Web

Web Assembly, the fourth language the web, found applications beyond the web in areas like Block chain, edge computing and cloud native applications

Who is unfamiliar with the three languages that make up the web - HTML, CSS, and JavaScript?  Apart from these, there is a fourth language that W3C included as an official web standard, which very few know about.  It is Web Assembly, aka Wasm.  Originally intended to be a faster alternative to JavaScript, using intermediate assembly code that can run in the browser directly, has now garnered interest beyond the Web. 

Figma was recently acquired by Adobe for $ 20 billion, making it one of the biggest acquisitions by Adobe.  Part of Figma’s success is its smooth and highly performant UI delivered on a browser. Figma has made collaboration so easy for UX designers, product managers, and developers, which probably made it so valuable, which made Adobe acquire it.  Thanks to Wasm & WebGL, Figma is able to deliver native UI-like performance & experience on the web.  Wasm is such a critical part of Figma, that it is also used in their plug-in architecture. 

Figma @figma

One of the craziest things we tried when building Figma's plugins API was to compile a JavaScript engine to WebAssembly. Inception much? Learn about our other experiments here:

figma.comHow to build a plugin system on the web and also sleep well at nightThe solution we found helps us run Figma plugins in a safe way — i.e. not eval(UNTRUSTED_CODE).

Wasm is Secure and Portable

Performance is one of the key reasons to use Wasm, but security and portability are the other important ones.  To me, Wasm feels like a throwback to Java applets (JVM in browser), but much better and more relevant in the current times. Wasm runs in a sandbox with no direct access to host features, which makes it an excellent fit to run untrusted code.  More importantly, Wasm is portable and doesn't require learning a new programming language.  Code can be written in high-level programming languages like C, C++, Go, Rust, C# and Java can compile to wasm. In addition, there are exclusive programming languages such as AssemblyScript (a variation of Typescript), and Grain which natively targets Wasm. 

Why is it not so popular then?

While the case for Wasm on the web is interesting, the combination of HTML and Javascript offers a much simpler alternative for building web applications.  Javascript engines in modern web browsers are performant enough to cater to the majority of cases.  Combined with plenty of choices with application frameworks, mature tooling makes it hard to consider Wasm.  If ain’t broken, why fix it?  This explains why it is not so popular.  

Current use cases for Wasm on Web are primarily compute-intensive tasks in the browser such as image processing, games, audio processing, and highly intensive compute logic, AR/VR, crypto, and plug-ins.  Using languages other than Javascript for web development is another interesting idea.  Microsoft’s Blazor is an excellent example, of how C# can be used for web application development, apart from using it for building native applications.  Blazor applications use C# but generate Wasm to run on the browser, while natively using C# on the server side. 

Beyond Client

While Wasm was originally intended for the browser client, it found unlikely friends elsewhere. The story here is somewhat similar to Javascript, and how it is now popular on the server side with Node.js and Deno.  However, the portability, security, and performance of wasm are much more powerful and go beyond what Javascript can do.  In this case, open-source standalone Wasm runtimes have upped the game.  Open source projects like Wasmer (backed by wasmer.io), Wasmtime (backed by Bytecode Alliance), and Wasmedge (backed by CNCF), allow wasm to run anywhere in a portable and secure manner.  Well, isn’t that what containers (Docker) are supposed to be?  The founder of Docker, Solomon Hykes agrees.

Solomon Hykes @solomonstre

If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!

Lin Clark @linclark

WebAssembly running outside the web has a huge future. And that future gets one giant leap closer today with... 📢 Announcing WASI: A system interface for running WebAssembly outside the web (and inside it too) https://t.co/HdEAZAyqYu

Serverless and Edge Cloud Native Applications 

Imagine writing code in a language that can compile to Wasm, and can run in a sandbox, and can run on any platform. Wasm offers a lightweight alternative to containers, which makes it a compelling choice for cloud native applications.  With the help of WebAssembly System Interface, or WASI, the Wasm code can communicate with the hosts in an explicit way, making it interoperable with other microservices, which is a key requirement for use in cloud native applications. Since wasm start-up times in milli-seconds, it does make a good choice for building cloud native services. Serverless and Edge are the two popular use cases of Wasm now. Leading CDN and Edge Application Platform provides Fastly, Cloud Flare both offer Wasm based edge computing options.

Krustlet is an open-source Kubelet that offers a way to deploy Wasm based code (developed in Rust) on Kubernetes. Docker has recently announced integration of Wasmedge into Docker tooling.  It is a technical preview, but that makes Wasm an integral part of cloud-native tooling.  

Decentralized Applications

Decentralized applications that run on Blockchain also offer interesting challenges that wasm can address.  Writing DApps/smart contracts in any language, and then targeting a Wasm based on-chain runtime to execute them offers much more flexibility than using a single language like solidity which can only run on Ethereum.  Both Polkadot and Cosmos use Wasm as the choice for developing Dapps.

What is next for Wasm?

It is natural to question what is next for Wasm, given the flurry of seemingly unrelated use cases of Wasm is trying to address.   

Wasm on Client

My view is that Wasm on browser use cases will continue to be limited to special cases that require high performance such as those I’ve mentioned with Figma.  Unless there are compelling frameworks like Blazor for other languages which make developers consider Wasm, I don’t see Wasm disrupting traditional web application development in any way. 

If the vision of Metaverse truly takes off, and should the need for interoperability between proprietary metaverses rise, Wasm would make an excellent choice.  Wasm can provide the underlying infrastructure using which users of metaverses can seamlessly move their avatars and assets.

While it is a distant dream, Wasm can be the underlying technology that can make true universal applications that can run on web browsers, desktops, smartphones, and servers possible.  

Wasm on Edge & Cloud

This is where the future of Wasm is.  Without sounding too repetitive, the multi-language nature of Wasm really makes it an excellent choice.  However, the current toolset is too limited to make that happen.  True cloud-native applications require a variety of capabilities such as composing, discovering, and orchestrating multiple microservices, which is primitive at this point.   

The recent announcement from Docker+Wasm integration is very positive.  PaaS Cloud offerings from Fermyon and Cosmonic are very interesting as well.  Both these platforms offer a simple way to deploy wasm applications at the Cloud scale.  

However, I believe the lack of maturity in tooling, flux in the standards, and not so much push from the big cloud vendors such as AWS, Google, and Microsoft, will prove to be adoption barriers.

A recent survey by CNCF at Kubecon captures the developer sentiment and the barriers to Wasm very well. 

Investment Guidance

Wasm is interesting and has many compelling use cases even right now.  

• If you are building a SaaS platform and looking for a way to offer user-defined plug-ins, Wasm makes perfect sense right now.   

• If you are building games, processing rich media on the web, and looking to improve your performance, Wasm is definitely worth considering.

• If you are developing edge applications or building an edge computing platform, Wasm is a great choice.

The following cases are not sensible yet.

• If you are a web application developer, the current generation of frameworks is very capable, and wouldn’t recommend Wasm.

• If you are a cloud-native application developer - While there is significant hype about using Wasm for cloud-native applications, Wasm is interesting but not very mature. At this point, I wouldn’t recommend using it. keep watching the space for now.