Why Blazor, via WebAssembly, is the future

I’m going to go out on a limb here and make a prediction. Since the web’s inception, much of our industry has spent effort to be on the web but to escape web technologies like JavaScript, HTML and CSS. Examples include Java Applets (1995–around 2013), Microsoft ActiveX (shipped with Internet Explorer 3.0 in 1996), Microsoft’s ASP.NET Web Forms (2002), JavaServer Faces (JSF), the Google Web Toolkit (2006), Microsoft Silverlight (2007) and numerous “compile-to-JavaScript” languages and transpilers.

The widespread dissatisfaction with JavaScript as a language has existed since its early days and can be seen through repeated attempts to extend the language with static typing. This goes all the way back to the draft of JavaScript 2.0 in 1999, Microsoft’s JScript.NET in 2000, Adobe’s Action Script 2.0 in 2003 and the failure of ECMAScript 4 that same year, Google’s Dart in 2011, Microsoft’s hugely popular Typescript in 2012, Google’s SoundScript experiment in 2015, and Facebook’s Flow in 2016.

Today, we have Web Assembly, which has been implemented in all major browsers since late 2017. So, why is this, and Blazor, any different than the above technologies?

All of the technologies that have come before have been one of two things — either a browser extension that exists outside of the browser’s security sandbox, or a layer on top of HTML, CSS and JavaScript attempting to abstract away web technologies and even protocols.

WebAssembly is different, in that it is native to the browser, is itself a standard web technology, and operates within the same sandbox as JavaScript. As a result, browser vendors can ensure WebAssembly is a more secure product and it does not require users to install or update anything apart from the browser itself. WebAssembly is expressed in byte-code and packaged in binary (as opposed to plain text JavaScript), giving it efficiency and compactness JavaScript tooling can only dream about.

As a low-level language, WebAssembly isn’t appropriate as a target for developing web applications, as it’s intended to be a better compilation target for other, higher-level languages that before could only be compiled, or “transpired”, to JavaScript. Today, WebAssembly also lacks direct access to the DOM and other browser APIs. All of this is where Blazor comes in.

Blazor allows you to compile a .NET app, stripping down the framework and bits to just what is absolutely needed to run the app, and execute .NET code in the browser natively. You can literally build a client-side web app with C# and Razor templating. This differs from trans-piling to JavaScript in huge ways — it’s much faster and it has more flexible options for storing data in memory (ie: isn’t limited to things like JavaScript number or Int32Array). Blazor also includes the glue code needed to interact with the DOM from your .NET application in a performant way. Blazor also utilizes source maps so you can actually debug and step through your C# application in the browser. This, by itself, is an amazing feat of engineering.

Because Blazor enables sharing class libraries and code written in C# between the browser and the server, type definitions and data structures can be shared and verified anywhere in the stack. This brings richer type information, security and confidence than adding type checking layers on top of JavaScript can bring.

Blazor can also interop with existing JavaScript with relative ease. You can both invoke static .NET methods from JavaScript, or invoke JavaScript functions from Blazor.

Because Blazor apps are developed with C# in Visual Studio, you can enjoy the rich ecosystem of tooling that already exists for .NET applications. Which brings me to my next point.

The promise of ASP.NET Web Forms allowed .NET developers to forget about web technologies. Creating a page-able, sort-able grid was as simple as dragging and dropping a control onto a WYSIWYG editor. Adding click events to a button in the browser that did something on the server was as simple as double-clicking that same button in the editor and writing some C# code. I’ve watched countless .NET developers struggle to evolve along with modern web technology. It’s not entirely their fault as everything is changing so rapidly and in the ASP.NET Web Forms world, everything was basically handed to you. Many C# and VB.NET developers still haven’t made the switch.

There’s another group of people that I think will also be happy for Blazor’s arrival. Many .NET developers work in shops that enforce a homogeneous tech stack from a single vendor — like in the finance and healthcare sectors of our industry. To develop modern web applications today in Angular or React is very frustrating without unfettered access to npm, github, and stack overflow, but that wont stop large and slow-moving organizations from enacting policies seeking to lock down every aspect of the development life-cycle process. Blazor would, in theory, allow such organizations to mandate a single application programming language across the stack, which has the added benefit of making hiring and auditing easier. So where do these shops often get their components from? 3rd party vendors with licensing agreements that can offer paid support options like Telerik already have a suite of Blazor components ready to go.

Another place where the Microsoft stack seems lacking is with cross-platform desktop application development. Because WebAssembly is a web technology, people are already experimenting with it in Electron, which uses the same components the Chrome web browser uses to render its UI, allowing developers to package a Blazor app that can run on Windows, Mac OS and Linux.

Want to develop server-side applications with Blazor? You can do that. WebAssembly itself can also run within a server-side node.js application.

Want to develop mobile apps with Blazor? While Xamarin has long been an option for developing mobile apps with C#, and Blazor already runs in mobile browsers, there was some experimental stuff presented at NDC Oslo that combined Google’s Flutter with Blazor (towards the end of the video). Flutter itself has platform support for iOS, Android, the Web, React Native and, also supports Xamarin. Mac OS, Windows and Linux support is at various stages, but is being worked on. There are also some experimental projects out there combining technologies like React Native with WebAssembly directly. If I were to make another prediction, it’s that there will be, soon enough, a first class solution to building Blazor apps as native mobile applications similarly to how React Native apps are built today.

In Conclusion

It’s been a long road to get here. While WebAssembly was never intended to replace JavaScript, I knew the moment our industry had the option to develop web apps native to the browser in their favorite languages, it was only a matter of time before developers started to try. Although Blazor started as a third-party, open-source project outside of ASP.NET to see if such a thing were viable at all, Microsoft had the foresight to bring it into the platform and make it part of the stack. .NET has a vibrant ecosystem, and it’s not hard to find C# jobs in many places of the world. C# as a language continues to evolve and adopt features from other languages like pattern matching, switch expressions and making references non-nullable by default. With the arrival of Blazor, C# and .NET on the web is sure to have a very bright and exciting future ahead.