Microsoft’s Blazor WebAssembly presents a radically new approach for developing and deploying browser-based business applications. While we’re starting to see increased interest from many of our clients, we’re also observing a certain amount of skepticism in the market and some early-adopter anxiety amongst development teams.
Now, with Blazor, Microsoft offers developers the opportunity to deliver web applications using .NET languages, libraries, and runtimes inside the browser. But surely this is just the next failed experiment in Microsoft’s long-running effort to work around—instead of through—core Web technologies, right?
We disagree. In fact, we think this current offering could be the basis for a long-term unification of how we develop user interfaces across a spectrum of delivery models: online, hybrid, desktop, and mobile. So what are we seeing in Blazor that makes us so confident that it’s not “just another Silverlight”?
Opaque to the end user
This is probably the most important difference between Blazor and other alternative approaches to web application programming that Microsoft has offered. Unlike prior technologies, Blazor requires no extra commitments by end users, rendering their experience more seamless. Back when Internet Explorer held 95% of the browser market, Microsoft could encourage proprietary interfaces like ActiveX Controls that only ran there. Today’s market doesn’t support that type of exclusivity.
Removing end-user installation and acceptance is not only great for user experience, it removes one of the biggest barriers to developer team adoption: having to enlist customers in a new rollout.
Any browser, any OS
Previous forays into alternative web programming usually involved some kind of lock-in. For example, VBSCript ActiveX only ran inside of Internet Explorer. Silverlight relied on open source ports of their runtime in order to run on Linux, and Mac support for it lagged several years behind the Windows editions. Of course, none of those earlier ventures supported mobile browsers at all.
Because Blazor is built on top of existing, open web standards like WebAssembly, it doesn’t require any specific product lock-in by either users or developers. Blazor lets you code where you want, deploy where want, and run your applications where you want.
Multiple runtime modes
Most web application frameworks take a hard stance on optimizing either for server-side or client-side UI rendering. This makes certain frameworks more or less appropriate, depending on the nature of the application and devices it’s going to run on. Blazor’s architecture team has adopted a deliberate “Support the Spectrum” approach by separating the core programming technologies (Razor Pages and Components) from their various runtime environments (Server and WebAssembly today, with Hybrid and Native options in early prototypes).
This evolving approach means Blazor will support a full spectrum of application deployment models: from 100%-online, always connected web applications to (in the future) 100%-native mobile applications. This is something we haven’t really seen before from any user interface platform.
In our own experiments with Blazor, our engineers have been encouraged by how much reuse we got from our user interface code (over 97%) when switching between Server and WebAssembly hosting models. This will give more teams an opportunity to adjust between Blazor runtime models as their applications evolve, without having to start a completely new development project.
Although Blazor applications are most easily built when you’re starting a new project, they’re also easy to host inside of an existing asp.net core web application. You can make deliberate, informed decisions about how and when to incorporate both Server- and WebAssembly-hosted code into your existing apps.
For end users, there’s no impedance between the two. An embedded Blazor application—much like a React App in a larger site—just looks like part of the parent application. But this incremental hosting approach allows development teams to employ a “land and expand” pattern. You can incrementally migrate more and more of your applications’ code to Blazor while maintaining continuity of service to end users. You also don’t need to maintain feature parity with production services while working in a greenfield rewrite.
Because Blazor and standard ASP.NET Core application code can live side-by-side so easily, there’s very little barrier to incremental, progressive adoption of the platform.
We might be wrong, but we believe Microsoft got it right this time. What we see in Blazor is a standards-based application development platform for the web that:
- Includes broad browser and operating support
- Requires no extra installations or plugins
- Provides a secure, portable, simplified development experience for .NET teams.
We’re also encouraged by the rapid, transparent delivery of both Server and now WebAssembly versions of the framework.
There are certainly no silver bullets. For instance, server-side pre-rendering and client-side debugging still have plenty of room for improvements. However, Blazor could be the first step towards a unified, cross-platform UI framework with significant potential to development costs and increased performance profiles in production. Especially for teams already delivering solutions on the .NET platform, the barrier to entry is low. All this makes Blazor well-worth considering as a viable option for evolving your traditional web development approaches.