4 reasons Blazor is the next step in web programming

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.

This is understandable. For as long there’s been an internet, Microsoft’s been trying to find a way to “embrace, extend, and extinguish” the space. But if we look back at the last 25 years, we’ve seen the failure of such efforts as introducing proprietary HTML elements in the first versions of Internet Explorer, pushing the use of ActiveX Controls inside of applications, trying to replace JavaScript with VBScript, and the launching the Silverlight runtime and programming model, which was famously abandoned.

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.

End users of your web application won’t even know that Blazor is behind it: There are no plugins to install, and their experience is exactly the same as if the application had been written in typical JavaScript, HTML, and CSS. Because it runs in all modern browsers—including mobile devices—there’s no need for your users to switch between browsers to get to a certain site or application.

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

Blazor Server and Blazor WebAssembly both run .NET code, but ultimately render standards-compliant HTML and CSS, and even support interoperability with existing JavaScript libraries. Because the client-side runtime is hosted inside the WebAssembly sandbox, Blazor can run on any modern browser, on any modern OS. That means Windows, Mac, iOS, Android, and any other operating system that provides a modern, standards-compliant web browser.

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.

Progressive adoption

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.

Let's Talk