When i first met Blazor, I was amazed by the audacity of the idea. Rather than trying to plug something else into the overloaded JavaScript ecosystem, Microsoft was going to start from the ground up. Again. (Those of you who remember their doomed Silverlight adventure don’t need another reminder.)

It’s hard to overstate the importance of JavaScript today. It’s not just the dominant ecosystem for browser-based web applications. It’s the only ecosystem for them. And while Blazor isn’t entirely JavaScript-free (someone still needs to communicate with the HTML DOM, whether it’s your code or a component you’re using), Blazor brazenly demotes JavaScript to a minor implementation detail. The goal is to write all your business logic and everything important in pure C#.

The technological underpinnings for Blazor are rock solid. It’s built on WebAssembly, a cross-platform standard that has significant vendor buy-in, universal browser support, and better performance than even today’s optimized JavaScript engines. WebAssembly also has some jaw-dropping proof-of-concept demonstrations, like 3D games and emulators running natively in the browser. Writing directly in WebAssembly isn’t really an option, because it’s a heavily condensed intermediate language. But compiling to WebAssembly or using someone else’s WebAssembly-based application engine makes good sense. So why wouldn’t we use WebAssembly to build a completely new framework that’s unencumbered by the quirks and history of JavaScript? (Short answer: because it’s very difficult to get it right.)

I took my first look at Blazor almost exactly two years ago. The early verdict was divided. Blazor was an interesting experiment — on the cusp of greatness, but not a practical drop-in solution for anyone’s current problems.

But how about now?

The limits of Blazor today

In the tech community, opinions about Blazor have coalesced. Whether you’re a Blazor fan or critic (or both), there’s a broad agreement about what’s propelling Blazor forward — and what still might hold it back.

Blazor’s biggest problem is a small but non-negotiable performance hit. Even in today’s world of modern internet infrastructure, Blazor has a startup tax, and a small but somewhat more significant first-time-launch tax. This is the only issue that’s truly fundamental, because it can’t be fixed by future iterations of Blazor. All we can do is wait for improved internet infrastructure to grow us out of the problem.

If you’ve used Blazor, you’ve probably seen this message, crammed in the top corner of the window when an application is about to appear, and looking slightly embarrassed about itself:

Blazor uses this moment to download an embedded version of the .NET runtime (compiled to WebAssembly), along with DLLs for your application and the .NET class libraries it uses (compiled to Microsoft’s Common Intermediate Language, just like every version of .NET since 2000). The download size is a non-negotiable 2 or 3 MB. The startup delay ranges from fractions of a second to several seconds or — occasionally — even more.

No matter how short, a loading screen on a web app has distinctly negative connotations. It calls to mind legacy web technologies like Flash and (for the truly old among us) Java applets. In some environments, Blazor’s lag is an automatic deal breaker. But there are mitigation strategies, such as caching by CDN, an ahead-of-time compilation feature that’s coming in .NET 6 (scheduled for November 2021), and different types of optimization like tree-shaking, which are always improving. But no matter what improvements Microsoft makes, Blazor won’t reach the raw startup speed of JavaScript.

If that disqualifies Blazor for some people now, it doesn’t disqualify it forever. After all, WebAssembly itself is a blisteringly fast technology. It’s possible that Blazor could close the performance gap in other areas. Imagine a CPU-intensive app built in Blazor (think data science or DNA sequencing), with performance that surpasses the JavaScript version in everything but startup. Right now this kind of work is often done with Rust (which also compiles to WebAssembly) or transpiled from C++ with Emscripten. But both approaches are part of a small and specialized niche of web development. It Blazor could open the door wider to optimized browser applications, it’s startup lag might not matter so much.

Could the startup lag disappear? In today’s world, bandwidth continues to grow under a scaled-down version of Moore’s Law. That means the performance penalty that exists today for Blazor is only going to dwindle over time. It’s possible that the penalty will never become negligible. But did anyone predict a decade ago that the performance of JavaScript would increase to the point where we can run things like Electron, which hosts not just a separate instance of the JavaScript engine for every app, but also a separate Node.js web server to power its backend? And that the performance would be good enough that we could use this approach to build the world’s most popular code editor?

The steady rise of bandwidth over time

Another potential problem with Blazor is its baked-in application model, which borrows heavily from Microsoft’s server-side web framework, Razor. This design choice makes some sense, because it gives Microsoft developers a place to start and a way to orient themselves in the Blazor world. And it’s perhaps too much to expect Microsoft to reinvent every part of the application model while introducing a new WebAssembly-fuelled runtime. But still, the Razor trappings can seem a bit arbitrary. We don’t need to be wedded to the past — after all, the JavaScript past has lots of ugly in it. But it’s fair to ask if Blazor’s Razor-flavored model is really the best possible abstraction.

The future: a web decoupled from HTML

In one way, Blazor is thoroughly modern. It embraces the growing (and often controversial) trend of building web applications that gradually becoming more abstracted from HTML. Industry leaders like Google are building applications that paint their interfaces using the canvas element, rather than modelling it out of discrete HTML elements and interacting through the DOM. JavaScript frameworks like React have component libraries that let us program against higher-level controls, rather than HTML forms and divs. Flutter is creating a cross-platform layout engine that also relies on WebAssembly.

Whether we like this trend or not — and there are plenty of drawbacks — it’s a movement that’s poised to grow well into the future, whether you’re building with Blazor or a JavaScript framework. And even though the Blazor ecosystem started from scratch just two years ago, it already features a wide range of polished component libraries, many of which are free even for commercial use. Consider the offerings from MudBlazor, MatBlazor, Radzen, Ant Design, Telerik, and the Blazored collection, to name just a few promising options. If you want nicely styled charts, data grids, carousels, toolbars, and other bits of UI magic, the only problem is deciding which library is likely to have the best adoption and support going into the future.

A gauge control for Blazor from Radzen’s UI toolkit

Today’s verdict

Blazor is a tough sell to current web developer, because it means leaving behind many of the libraries and technologies that have been up over a decade of modern JavaScript development. It’s not a seamless transition, and there’s no way to migrate a JavaScript application to a Blazor project. Switching to Blazor still means moving from the rough seas of JavaScript to a much smaller swimming pool. Most developers are going to check it out but won’t be ready to leave the ocean just yet.

For experienced C# developers, it’s a different story. If you have a team that knows .NET and they’re building an internal business application, Blazor lets them be more productive and build the front-end and back-end with one stack. If you were considering a Windows desktop application (built on something like WPF), Blazor is a more future-forward choice. But if you’re a business building modern, public web applications, there’s very little chance you’ll recommend a client start with Blazor today.

The bottom line? Blazor’s a niche — a powerful one — best suited to Microsoft developers who love .NET and C#. But don’t let the present blind you to the future. There’s a lot of promise in stacks that build on WebAssembly, and a lot of room for other languages to nibble away at the edges of JavaScript. And in the ever-changing world of web development, we’re overdue for another revolution.