Why I Think WebAssembly is a Bad Idea

If you haven't discovered WebAssembly yet, it's a pretty exciting technology that allows you to code in a range of languages (C++, Rust, and Typescript most notably) then compile your code into a WASM file that can run in all popular web browsers. Because the code is compiled it runs quickly and consistently across all devices. WebAssembly can't render directly and has to rely on being called by and emitting Javascript to manipulate the DOM, but it still opens up some exciting options and introduces the potential to do things in the browser that we just can't do right now like 3D games, heavy image manipulation, cryptography, etc.

Sounds pretty cool right? Well, that's not all - a lot of big names are using WebAssembly including Disney+ and Shopify. There's a growing list of projects using WebAssembly at https://madewithwebassembly.com/

So, if I'm telling you about a new way of writing code for the web that's quicker, more portable, and lets you use the language of your choice... why do I think it's a bad idea?

Well, we've been here before. More than once. We've been here with Java Applets. We've been here with ASP.net. And Flash. And Silverlight. In fact, it's one of the negative patterns that we just don't seem to be able to break in computer programming; we take a working client-server model and we try to make the client fatter and thicker and get it to do more heavy lifting. Then, after a while, we realize the error of our ways and we break things apart again.

We did it with the PC. We did it with the smartphone. We did it with wearables.

We just can't stop trying to load more processing and activity into the client-side, a pattern that always ends up being reversed.

Yes, WebAssembly is good at "heavy lifting"

Here's a great example of a project made better with WebAssembly. It's a clever piece of software that helps researchers and scientists preview the quality of DNA sequence data. It needs to do some heavy lifting and moving this functionality out of Javascript and into WebAssembly brought some significant speed benefits to the application.

This doesn't mean by default that WebAssembly is always faster than Javascript. Actually, if you're not doing something computationally complex, the chances are good that WebAssembly will actually be slower than Javascript, like in these examples.

Now, I'm not criticizing the developers of this application, they've made something pretty impressive, but I've got to ask the obvious question... why do you need to number crunch DNA samples in a browser in Javascript in the first place? Personally, I wouldn't do this on the client-side unless I absolutely had to... and I don't have to.

But where you do your heavy lifting matters...

Let's say I have an application that needs to do some audio manipulation. I want to do it in the browser as part of a larger software as a service application, so this is doable in Javascript but computationally intensive. I could get the data pushed up to my server and process it there, but that's going to increase the load on my server so I'm going to need a bigger server or to set up my server to expand itself elastically as I need it. WebAssembly makes some sense here, because I can make the client do the work.

However, this makes the fundamental assumption that every client device has enough computing power to do what we want it to do. In a world where we have a shortage of microprocessors that is likely to last for another few years, increasing costs, and lower-powered devices (like Chromebooks) becoming more popular, why are we trying to push processing back on to clients again?

We did it when terminals became PCs, then moved everything to the web. We did it with smartphone apps, which we are now replacing with PWAs and single-page Javascript applications. We're doing it with wearables and will inevitably flip back the other way there too.

Web Assembly for Serverless Computing

There's a lot of buzz about "serverless computing" at the moment, but for me that doesn't mean pushing processing back to the client-side. Serverless computing means running code in the cloud without having to invest in a whole server to do it. It's about time-slicing a much bigger machine into much smaller increments than we currently do by allowing us to grab some resource on an "as we need it" basis from a large pool rather than ring-fence a chunk of resource and then waste it when we're not using it.

Even an elastic server will waste resources, running at its smallest possible size while idle is still running. Serverless computing allows us to "scale to zero" - zero running costs when we are not running.

Cloudflare is one example of WebAssembly being used right - as a remotely executed, serverless piece of code. In this example, Cloudflare show some image resizing being done "at the edge" using a Cloudflare Worker. It's quite neat, although in real terms doesn't offer anything you couldn't do with a simple server-side PHP script, Javascript file, or any other way.

The AutoCad web app is a far better example (although not as clearly explained as the Cloudflare proof of concept). Here, all the heavy lifting is done remotely so your system requirements are minimal. WebAssembly is a good choice for this as CAD is computationally expensive and has, historically, needed some beefy client-side hardware to run.

As a way of delivering more complex code and allowing it to run fast on a low-powered device, by leveraging external resources, this model makes sense and is scalable for the future. Moving complex processing client-side isn't a good idea, unless you absolutely have to.

Mostly, it comes down to bandwidth

One of the things that people say that they want to do with WebAssembly is make games that run quickly in the browser. Sounds cool... except we already have this, and it's called Stadia. Stadia is Google's streaming games platform, an environment where the game (the heavy lifting) runs remotely and streams the video and audio to your computer. Stadia makes it possible to run even incredibly complex and resource-hungry games, such as Cyberpunk 2077, on relatively lower-powered hardware (like my four-year Chromebook). I don't care how fast WebAssembly might think it is, but when the game recommends a $400 graphics card as its minimum spec, that game is not running in a browser on a Chrombook. Ever.

The only obstacle to improving the performance of server-side computing of this sort is bandwidth and this is one area of computing where we still see exponential improvement in capacity coupled with falling prices. (And yes, there is such a thing as 6G...)

Should I use Web Assembly?

If I haven't made it clear enough yet, there's one good use case for WebAssembly right now and that's if you've got heavy lifting to do. The other oft-touted reason to use WebAssembly is that it lets you write in a wider variety of languages than you currently can for the web. Sadly, this is a lie... and not a very useful one.

Webpages are written in HTML, CSS, and Javascript. With WebAssembly they still are - you're just calling an external WASM using your Javascript and then handling the output it gives you, manipulating the DOM, etc. So, if you don't know HTML, CSS, and Javascript and you're thinking WebAssembly will save you by letting you carry on programming in FORTRAN or whatever... forget it. WebAssembly doesn't do that.

Also, what is our obsession with trying to program for the web in old languages? There's a reason that your toolbox at home contains more than one tool. It's because different tools are good for different things. The same is true of programming languages. If you're so desperate to write code for the web in FORTRAN though? Have at it - just build a HTTP server in FORTRAN and then write server-side code to your heart's content. That's the point of writing server-side code; it doesn't matter what language you write your code in, I'm only ever going to see the output (which will be in HTML, CSS, and Javascript).

What's the future for WebAssembly?

I'm old enough to remember when all websites were going to be replaced by Java applets. It didn't happen. The general web as we know it is not going to be rewritten in WebAssembly any time soon, nor are technologies like Javascript (which is hugely popular right now) going to go down without a fight.

Everyone said node.js would kill PHP. As of January 2022, PHP still runs 77.8% of the web.

Wide-scale WebAssembly adoption is a long-way off and it would not surprise me one bit if Javascript found a way to surpass the speed benefits of WASM before the new technology can really find its feet.