Is JavaScript on the Run with WebAssembly as a Replacement?

JavaScript is a language that has given us the world in which we live in. ATMs are running it, as well as healthcare gateways, VOIP phones and many others. An alternative is already on the horizon, though. It’s called WebAssembly and it’s grabbing the attention of power developers, ready to breathe fresh air into the world of high-level languages like C#. Is WebAssembly an alternative or the full-blown successor? What does it mean for development?

JavaScript and WebAssembly development

JavaScript and WebAssembly are absolutely within our limits. First, let’s think about the basics for both, or three of them since TypeScript is also gaining ground.

First things first. TypeScript is nothing more than an overlay for JavaScript, that provides strong typing. JavaScript is an interpreted language. Meaning, that the whole source code is sent to the customer, there loaded and run by an interpreter. Naturally, there are mechanisms that make reading algorithms harder (e.g. compressing files by shortening names of variables and functions or removing whitespace characters), but it’s still a source code and the processor still has to waste time on interpretation.

Alternatives for JavaScript don’t have its faults. Languages like C# or C++ are seasoned standards and welcomed tools in day-to-day work. Developers use alternatives because the originals usage of JavaScript was a little different. The non-stop evolution of web applications and the necessity of creating very complex interfaces forced developers to look for languages of higher efficiency. Of course, there were technologies that allowed the running of compiled code (for example Microsoft’s Silverlight) but they demanded an additional plugin for the browser. A similar situation occurred with Java. JavaScript has a ‘little’ advantage here – it’s natively supported by every browser. Recently a new web standard appeared and it’s supported by all the biggest browsers out there. It’s called WebAssembly and here’s what you need know about it.

WebAssembly Technology

WebAssembly (also called Wasm) delivers the customer the binary code, not the source code. This gives an additional protection layer. You can naturally still decompile this code and read it out loud, but it’s a lot harder than you think. Because of the interpretation of algorithms during the loading of the scripts, JavaScript is way slower in comparison to solutions used with C# or C++. WebAssembly supports languages allowing for manual memory management without Garbage Collector. It allows for better optimization. We have to remember though, that manual manipulation of the memory, if done by inexperienced developers, can create more damage than profit. For the safety reasons, the low-level code shares the memory with JavaScript and it’s limited to operate on objects that were made available by the function WebAssembly.Memory(). To make it simpler – it has access to assets we give it and can’t step over the lines drawn by the ‘sandbox’ of the browser.

It’s worth mentioning that WebAssembly has not been created to replace JavaScript but only to fill some blanks. The main and natural usage for the WebAssembly is for power-hungry and demanding applications such as video games, professional mathematical tools or even multimedia. It has some clear advantages, too! Among them are NuGet and MSBuild, as well as Blazor (more below), which is easy to use and very functional.

When it comes to WebAssembly, there is one word that comes to mind. It’s not even ‘choice’, promoted here and there as a natural state for the stage, when two technologies compete for attention. It’s ‘cooperation’. Both run in modern browsers, very often simultaneously. Both are considered complementary to each other. Plus, WebAssembly wasn’t designed to dethrone JavaScript indirectly, but rather as a target for compiling an alternate syntax. It’s safe to say that low-level environments such as JVM, CLR, BEAM and others are destined for client-sided language development.

The last attempt of using C# in HTML turned out to be a success but only for a short while. JS frameworks for Single Page Applications like React, Angular or VueJS eclipsed Razor in recent years. The arrival of WebAssembly is a chance for C# to ensure its position among front-end developers.

Blazor technology

Then came Blazor. It’s an experiential .NET web framework that provides the possibility to create views decorated by C# like Razor, but now its supported by the browser natively and runs on the client-side. It runs inside the browser with WebAssembly as a sidekick. It’s the first succeeded attempt of creating a framework using C# to build the user’s interface that is natively supported by all popular browsers. Unfortunately, Brazor is still in its experimental phase and it runs code even 200 times slower than other frameworks in a standard environment. Blazor is even slower than JavaScript! I took some time and ran efficiency tests using fractal generation under canvas. Isn’t that a complete misfire on WebAssembly’s part? Isn’t that performance proof of missing the target here? With the current efficiency, Blazor can’t compete with JavaScript but it’s worth mentioning that repository is still active and every single week is rich with commits, they are available on GitHub. Although Blazor doesn’t meet requirements for building commercial products, it has great potential and it’s worth observing further developments of this interesting tool.

JavaScript and WebAssembly coexist right now. It doesn’t mean that things won’t go south in the future, but they are complementary to each other and support new and upcoming apps. JavaScript is most definitely NOT on the run, far from that.