Is Blazor actually any good, beyond "demo-ware"

Blazor server has landed, Blazor Web Assembly is imminent (ish), and as people begin to explore Blazor more, it raises an important question;

Is “Blazor” actually any good for “real” applications?

Before we can even consider the question, we should probably define the term “good”.

For me, “good” comes down to a few key factors:

• Is it productive (can I build things quickly)?
• Is the tooling up to scratch (Does it have comprehensive support in Visual Studio etc)?
• Is it performant enough to use “in the wild”?

What follows is entirely subjective, based on personal experience, so take it with a massive pinch of salt!

I’ll update this page with new information as it arrives (as Blazor continues to be adopted in the “real” world).

Is it productive?

Blazor (Server or Web Assembly) employs a component model.

So, unlike say MVC, where each “View” is essentially an entire page, which you get back from the server when you make a request, Blazor deals in components.

A component can represent an entire “page”…

@page "/hello-world"

<h1>Hello World</h1>

… whereby you navigate to the component (as in /hello-world here) and it renders.

Or you can render components inside other components.

HelloWorld.razor

<h1>Hello World</h1>

Index.razor

@page "/Index"

<HelloWorld />

This approach shares quite a lot of similarity with several javascript frameworks, including React.js and provides a really flexible way to build a user interface.

The component model approach gives you a convenient way to take a mockup or design, break it down into smaller parts, and build each part separately (as components) before composing them back together.

(Image borrowed from Blazor by Example)

Here, each part of this interface could be built as its own component.

For example, you could build a UserName component so that any increase in complexity (for example, being able to hover over a user’s name to see more information) could be confined to the component itself.

Components also carry the benefit of being easily re-used.

Our HelloWorld component gets to go wherever we need it:

Index.razor

@page "/Index"

<HelloWorld />

Greeting.razor

@page "/Greeting"

<HelloWorld />
<HelloWorld />

And (as above) can be rendered as often as you like, even on the same page.

Components can take data in, and raise events when notable things happen (enabling the parent component can react to changes).

@page "/Index"

<Username Name="jonhilton" OnEdit="SaveChanges"/>

@code {
    protected void SaveChanges(CartLineItem item)
    {
        // save to DB
    }
}

Can you be productive building applications with Blazor? For me, this is a definite yes.

I recently had a go at building the exact same small feature in React (which I use virtually every day) and Blazor Server. I found the Blazor Server version quicker to build, and simpler to comprehend/alter afterwards.

Incidentally, I like React and will continue to use it both professionally and on my own projects; but Blazor’s component model definitely holds its own, and for C# developers will likely prove a much more comfortable step than jumping to JS (and everything that comes with it).

Is the tooling up to scratch?

You can build Blazor applications in Visual Studio, VS Code and JetBrains Rider.

I’ve tried Visual Studio so that’s what I’ll consider here.

VS does have some gaps in its support for Blazor at the moment, but nothing you’d probably call a show-stopper.

You can easily create a new Blazor project in VS, and edit the .razor files (which is the extension for Blazor components).

Debugging is supported so there’s no issue setting breakpoints and debugging your components.

Navigating to other components is a bit fiddly

I haven’t seen a way, when editing a .razor file, to navigate directly to other components.

In this example…

Greeting.razor

@page "/Greeting"

<HelloWorld />
<HelloWorld />

I’d expect to be able to CTRL+Click or F12 on <HelloWorld /> to jump straight to the code for that component.

Unless my IDE settings are wrong, or I’m missing a VS update, I haven’t seen this work yet.

It’s easy to work around (just navigate to the .razor file manually) but this is a feature I use all the time with React, so it would be nice to see it here too.

Refactoring support can be hit and miss

I’ve run into a few issues renaming a property on a model I’ve used in a component, where the component doesn’t get updated to reflect the new name. Again, this may just be my settings or an issue with my installation.

Overall, I would say the tooling works. It does have a hint of “early stage” release about it, with the occasional oddity and unexpected behaviour, but overall it works as you would expect.

I’m sure there’s more to come as MS continue to work on both Blazor and the associated tooling.

Is it performant enough to use “in the wild”?

This is probably the biggest question mark hanging over Blazor Server right now.

Blazor server does most of its processing on the server (hence the name), making your server (and network resources) the primary point of failure, and bottleneck when it comes to speed.

Every button click, or DOM triggered event (such as text changing in an input) gets sent over a socket connection to the server, which processes the event, figures out what should change in the browser, then sends a small “diff” up to the browser (via the socket connection).

This aspect of Blazor server is going to be affected by the latency between the user’s browser and your server, so if you host your site in America and serve users elsewhere in the world, the latency may be a factor.

It’s early days to know whether any significantly large-scale web sites are using Blazor Server.

This article from Microsoft is a useful guide to the kind of performance you can expect.

“In our tests, a single Standard_D1_v2 instance on Azure (1 vCPU, 3.5 GB memory) could handle over 5,000 concurrent users without any degradation in latency”

Based on this, for your average web application it seems the server resources wouldn’t be a major concern, but the network latency might be a factor.

Blazor Web Assembly removes this constraint, with events and DOM “diffs” being processed in the browser, but it also needs to download a version of the .NET framework, and your application’s DLLS to the browser the first time someone access your application.

This initial load will likely get smaller (as MS continue to optimise the framework) but this may be the significant factor to consider when Blazor Web Assembly lands next year.

Saying that, we’ve all seen some pretty big initial downloads for javascript based sites so…

In summary

In truth, it’s still a little early to know how Blazor holds up in the real world.

What we really need are case studies for significant scale applications.

In the meantime:

• the component model is very promising and offers a productive way to build “modern” web applications
• the tooling is sufficient (and likely to improve)
• and Blazor Web Assembly promises to improve performance (although Blazor Server might well be fast enough for your specific use case)

Interesting times ahead…

Next up