Microsoft has had plenty of experience with common language runtimes like WebAssembly’s. After all, .NET’s own CLR has been around for more than two decades now and has become the foundation for its open source reinvention, while supporting many different languages from a managed C++ implementation to the stalwart C# and Visual Basic and the functional F#. So, it wasn’t hard to provide tools for .NET’s Roslyn compiler to target the WebAssembly byte code rather than the .NET CLR’s.
Blazor WebAssembly tools in Visual Studio
The initial Blazor experiment built on the ASP.NET Core tooling to deliver WebAssembly code using familiar development tools and techniques. Now Blazor and WebAssembly are supported targets for C# development in Visual Studio. If you have a recent version of Visual Studio 2019 installed, start by creating a new project, and then choose to build a Blazor WebAssembly app. This will set up the scaffolding for a Blazor application, with an optional ASP.NET Core host, using either .NET Core 3.1 or .NET 5.0. I’d recommend .NET Core 5.0 for new development, but if you want long-term support you may prefer to choose the .NET Core 3.1 option.
The Visual Studio scaffolding is enough to get you started, providing a WebAssembly host for your code. You can then add controls as needed, using either the standard WinUI controls or working with third-party tools. Popular control vendors such as Infragistics have Blazor implementations of familiar controls with versions for both WebAssembly and server-side Blazor. Third-party controls like these let you build much more complex UIs, similar to those you’d use in a standard desktop application.
Once you’ve built a WebAssembly application you need to get it to your users. The Visual Studio tool gives you some options, but you need to either provide a complete web app for the ASP.NET Core option or use something like the Windows Store to deliver a WebAssembly PWA.
Using WebAssembly in Azure Static Web Apps
One option is to use the Azure Static Web Apps tool to deliver new code to a host URL each time you push a new build through GitHub. Code in a PWA or in a webpage may well be dynamic, but it’s not dynamically generated by a server. By building a Blazor app as a single page application, you can use standard switch and routing techniques to handle its different URLs, with a fallback route to ensure that any other URLs automatically resolve to the index view.
Azure Static Web Apps use GitHub to host your code, so Microsoft provides a GitHub repository with the files you need to build your first Blazor app. Start by using the provided template to set up your own repository, adding the main branch to your own account. You can then clone it to a local machine for editing in your choice of development tools. Once you’ve set that up, in Azure follow the usual route to create a Static Web App and connect it to your new GitHub repository. You can then deploy the sample code to Azure and test your app’s website. You can find the site URL in the Azure Portal.
With local code on your development system, you can open it in your choice of development tool, using either built-in Git tools or a Git client to push updates to your GitHub repository. It’s best to work in a local development branch, using pull requests to update the main branch. Once you’re happy with your code, accept the pull request and Azure Static Web Apps will use a GitHub Action to push a new build of both your site and your Blazor WebAssembly code to Azure. If you reload the site or a hosted PWA, you’ll automatically see any changes.
This approach makes a lot of sense as a way of transparently updating WebAssembly apps. Users will automatically be presented with a new version the next time they open the app’s URL, with no need to seek updates. At the same time, you don’t need to build an update infrastructure. A Blazor PWA delivered as an Azure Static Web App will look like a desktop app to a user, one that will always be up to date.
Taking advantage of WebView2 for WebAssembly
This approach makes it easier to update application logic out of band from standard updates. By refreshing the Blazor code, you can deliver updates without having to distribute a whole new release to users. This approach can work well when you’re having to respond to a rapidly changing regulatory environment, for example updating a realty app for new local taxes as soon as they’ve been approved, or calculating tariffs and other import duties while customs rules are still in flux.
Rapid changes aren’t the only reason to embed WebAssembly in an application. You can use it with WebView2 to A/B test new UI features, delivering different static content with Blazor components to different groups of users, experimentally verifying new application features before moving to standard WinUI components in a final release.
WebAssembly’s flexibility is key to much of its utility. Initially we’ll see it used as a Flash or Silverlight replacement, providing a way to host rich controls on ASP.NET Core web apps. Experience gained here will allow us to host those new experiences in desktop apps using WebView2 before we use them as PWAs delivered via Static Web Apps. There’s a lot to like about Microsoft’s measured and tool-driven approach to WebAssembly, and its rapid maturity means it’s time to start building your own Blazor-driven experiments.
Copyright © 2021 IDG Communications, Inc.