I’ve been looking at WebAssembly over the past few months. It’s a bit difficult to explain what WebAssembly on a .NET platform is. There is a .NET meta-technology called Blazor that allows Web applications to be developed entirely in C#, in other words, without using any JavaScript. But the C# code is then translated into standard HTML, CSS, and JavaScript so it can be consumed by Web browsers.

You can write a Blazor Web application using one of two different completely architectures: client-side or server-side. Server-side Blazor is most similar to “regular” Web development. A user clicks on a button on a Web page, the click is sent to the Web server, a new Web page is constructed and sent back to the user’s browser, and the new page is rendered. The back and forth communication is handled by a technology called SignalR.

Client-side Blazor is different. When a user requests a Web page, the page is sent from the server to the user but also a complete special runtime is sent. When the user clicks on a button on the page, all the logic is handled directly in the browser by a technology called WebAssembly. WebAssembly is a binary language that can be run in any browser that supports WebAssembly. The terms client-side Blazor and WebAssembly are roughly equivalent when on a .NET platform.

Left-Top: Blazor server-side architecture uses SignalR. Left-Bottom: Blazor client-side architecture uses WebAssembly. Right: The page counter example looks the same regardless of which of the two architectures is used.

The standard Blazor example is a Web page where the user can click on a button and the appplication keeps track of how many times the button has been clicked. You can implement the Web application using server-side (back and forth communication and page creation using SignalR) or client-side Blazor (a one-time download of the WebAssembly runtime engine and then all action happens on the client’s browser). To the user, both approaches will look exactly the same.

The Blazor WebAssembly project template generates a huge number of files of many different types — .css, .js, .html, .razor, .dll, and others. Even the simplest possible Blazor WebAssembly application is extremely complex.

Although you use C# to create a Blazor WebAssembly application, ultimately you end up with HTML, CSS, and JavaScript.

I have left out an enormous number of details but I’m stopping my explanation here to avoid going down a tech rabbit hole.

The .NET Blazor + WebAssembly is the latest in a long line of Web architectures and frameworks. I have suffered through Perl-CGI, classic ASP, ASP.NET, PHP, jQuery (the one Web library/technology I like a lot), Backbone.js, AngularJS, Angular, React, Vue.js — just to name a few. Will Blazor with WebAssembly catch on? I really don’t know. The world of Web development is impossible to predict. For creating a very complicated Web application, almost anything is better than trying to wrestle with raw JavaScript, but JavaScript has resisted all attempts to be replaced and just keeps chugging along.

The phrase “down the rabbit hole” comes from the book “Alice in Wonderland” by Lewis Carroll (1865). Left: The Disney animated film from 1951 scared me somewhat when I saw it as a very young man. I found many other depictions of Alice falling down the rabbit hole on the Internet. They all look rather scary to me — but not nearly as scary as the thought of having to use Angular.