We all remember Silverlight, Microsoft’s answer to Adobe’s Flash. The remnant of an ambitious plan to have .Net code running everywhere, it mixed the familiar C# and XAML with browsers. The result was a richer, more interactive web experience than familiar forms with a dash of CSS. As useful as plugins were, it became clear that they made the browser attack surface much bigger. Flash and ActiveX exploits became a serious security risk, and designers and developers began to back away from the world of plugins.
A new generation of more powerful browsers helped the transition, along with the opening of a corresponding new front in the never-ending browser wars: browser performance benchmarks. New JavaScript engines like Internet Explorer’s (and now Edge’s) Chakra came along with JIT compilers that took advantage of new processor capabilities and soon rivaled binary code. Along with better performance, the web itself added more capabilities, with HTML5’s new JavaScript and CSS constructs quickly providing alternatives to now-obsolete plugin technologies, from 2D animations to virtual reality.
Instead of plugins, we now use extensions. They’re safer, but they don’t have the speed or the capabilities of a plugin like Silverlight. Because they rely on JavaScript, HTML, and CSS, they provide seamless integration with the browser. But they don’t let us take advantage of advanced language features in C# or Go, or of newer hardware graphics capabilities.
WebAssembly is the power behind Blazor
Google’s experiments with NaCl, its Chrome native client, alongside Mozilla’s work with ASM.js, led to the development of the World Wide Web Consortium’s WebAssembly, aka Wasm. At the heart of WebAssembly is a simple virtual machine that can work with precompiled code that’s delivered in a compact binary encoding. Although WebAssembly code isn’t human-readable, the specification includes a way of representing it that looks very much like classic assembly language.
Any compiler can deliver WebAssembly code, from any language, and it can run nearly as fast as compiled binary code. There’s an added advantage too, because it only runs verified code in a browser-hosted sandbox. With the additional security features of a modern browser like Edge, the result is highly secure code that only has very limited access to system resources. That makes WebAssembly an attractive alternative to JavaScript, hosting fast and responsive web-based user interfaces.
Although still relatively new, WebAssembly is a surprisingly powerful tool, with support for a wide range of languages and platforms. The result is an effective replacement for the old plugin model of browser extensibility, maintaining the security sandbox but still allowing complex applications.
Microsoft has been experimenting with WebAssembly for some time now, with Edge providing support for WebAssembly tools. That’s led to the experimental release of Blazor, a new web UI framework from the ASP. Net team. Taking its name from a combination of Microsoft’s Razor web application syntax and browser, it’s available from GitHub with sample applications already live on the web.
Intended to support single-page web applications, like those produced by ASP.Net’s existing Razor environment, Blazor brings C# code directly into the browser with a .Net engine based on Mono that’s been implemented in WebAssembly. This approach makes web user experiences compatible with existing desktop applications, reduces the cognitive load needed when shifting between desktop and browser applications, and keeps code bases simpler and easier to manage.
What you need to start building with Blazor
Building a Blazor app is easy enough. You need the .Net Core 2.1 Preview 2 SDK, Visual Studio 2017 15.7 or later with the ASP.Net tools installed, and the Blazor Language Services extension (you’ll find it in the Visual Studio Marketplace). Once installed, apps are built from the Blazor template you find as part of Visual Studio 2017’s ASP.Net Core Web Application templates. One thing to note is that at this point there’s no debugger support, so once you’ve got code you can only deploy it to a local web server and browser for testing.
You use Blazor to implement client-side logic, much like you’d do in JavaScript. Code runs in the Razor single-page web application framework, implemented using a familiar model-view-controller (MVC) pattern. There’s little difference between Blazor and the familiar ASP.Net server-side web application model, though because Blazor code runs in the browser you need to consider how you’ll transfer data between your application and any back-end services. In practice, you can use .Net’s REST connectors to work with APIs generated by services like the Azure Mobile App Service.
Blazor isn’t only for C# development; its underlying .Net run time supports F# and VB as well, so you can quickly bring existing skills to the web without having to learn new languages. You can also share code between Windows projects and the web. Blazor also supports .Net Standard 2.0 (though it doesn’t implement all the APIs and you’ll need to check for NotSupportedExceptions).
Blazor code is precompiled into .Net assemblies, then downloaded and run on the Mono .Net runtime. Although .Net can be precompiled, generating application binaries, Blazor doesn’t supported this method currently; at this point it relies on Mono.
Blazor gives you progressive web apps with WebAssembly and Xamarin
Although it doesn’t go all the way down the Silverlight road, with no direct support for XAML user interfaces, Blazor does let you bring existing C# code to the web, adding complex business logic to your browser-hosted apps. That should help with progressive web application (PWA) development, bringing near-native speed code into your standalone browser applications.
One example uses an alternative .Net WebAssembly implementation to build a progressive web app that takes advantage of Xamarin Forms. Using Ooui.wasm, you can run XAML inside a web browser, on top of the same Mono-wasm .Net runtime used by Blazor. Although some issues remain, the prospect of bringing Ooui.wasm and Blazor together is attractive. Xamarin Forms’ cross-platform UI is a powerful tool, with the option of using XAML to layout user interfaces and customize the default forms.
Although Blazor is still an experiment, it’s a pointer to a possible future for web application development without HTML and JavaScript. It’ll be interesting to see if Microsoft continues with the Blazor experiment, and if future releases go beyond Razor single-page applications to handle Xamarin Forms and other UI options. Using the browser as a host for your code could give .Net a whole new audience, especially with progressive web app support now available across all the main mobile and desktop platforms.