Blazor Server or Blazor WebAssembly? Which one is better? Q3 2023

I have been an avid user of Blazor since its early stages, and I must admit that I enjoy both flavors of Blazor. A frequently asked question I receive is regarding the superiority between the two. In this blog post, we will first examine the key architectural distinctions between the two, followed by an exploration of why one should opt for one over the other. Subsequently, I will disclose my personal preference, and finally, we will delve into why this question may be misguided with the advent of .NET 8.

For a comprehensive breakdown of the variances between Blazor Server and Blazor WebAssembly, check ASP.NET Core Blazor hosting models.

Blazor Server Architecture

Blazor Server utilizes SignalR to communicate between the server and the client, as shown in the following diagram:

Blazor components are rendered within a render tree, which effectively monitors and detects changes by comparing the previous version of the tree. These changes are then transmitted to the client through SignalR in order to update the Document Object Model (DOM).

Blazor WebAssembly (WASM) Architecture

Blazor WebAssembly works in a very similar way with two main differences

  • Everything happens in the browser

  • WebAssembly does not have a direct access to DOM and updates DOM with JavaScript Interop (as opposed to SignalR)

Which flavor is right for me?

The short answer is ‘it depends’.

If you conduct a search on this topic, you will come across numerous reasons highlighting why one option may be preferable over the other.

However, I personally adopt a straightforward and distinctive approach. My preference is consistently towards Blazor Server over Blazor WebAssembly, unless I encounter specific constraints where the latter becomes necessary. These constraints typically include

  • The need for offline/PWA (Progressive Web App) functionality or

  • The requirement to access client device sensors and APIs.

But why?

  • I hold a genuine belief that many developers who embarked on their web development careers over the past decade have primarily worked with Single-Page Application (SPA) frameworks. Consequently, they may have never had the opportunity to witness the advantages offered by the server-side model (keeping in mind that Blazor isn't a traditional client/server model!). As a result, they may struggle to envision alternative approaches to web development. By the way, this model is called MPA if it makes it cooler!

    My personal standpoint is that server-side development brings forth numerous benefits, and it is crucial to have compelling reasons for forsaking those advantages in favor of SPA or exclusively using Blazor WebAssembly.

  • It is possible to swiftly build minimum viable products (MVPs) in a very hacky way and obtain iterative feedback promptly. I repeat myself, just to go through some iterations quickly and get some feedback; Not to build the future on top of a poorly written code!.

  • Development cycle is notably faster in the server-side flavor - and by this I don’t mean calling Entity Framework’s DbContext directly from razor component! Development cycle with Blazor server is faster even when employing proper architectural patterns such as Command Query Responsibility Segregation (CQRS), Event-Driven Design (EDD), and Domain-Driven Design (DDD). This accelerated pace of development extends to areas such as debugging, security implementation, and managing high-volume loads, providing a more seamless and enhanced experience for the developer.

  • Ultimately, from the end user's perspective, the application will feel like a SPA, regardless of the underlying implementation.

  • When considering massive scalability, Blazor Server may lead to increased expenses as it necessitates investing more in infrastructure. Therefore, the choice lies in allocating more funds towards development or infrastructure; And believe me Infrastructure costs less!

  • Blazor Server is more SEO friendly.

  • Initial load is faster (This will change in .NET 8 to some degree!)

You should ask a different question when .NET 8 is out!

.NET 8.0.0-preview.5 is here and has some very exciting features and changes for Blazor. Check Daniel Roth Post on .NET Blog.

With .NET 8:

  • You can mix and match razor pages (classic Client/Server) with Blazor Component. As a result, you can modernize classic web applications by adding more interactive UI-rich components. It also means you don’t need Blazor Server (read it as SignalR connection) for static pages!

  • You can load your web application as Blazor Server first (read it as client doesn’t need to download WebAssembly to start with!) and then load WebAssembly in the backend when needed.

  • You can compile the component on the server, and send back the rendered HTML to the client.

  • Blazor Server got a nice update for seamless reconnect.

I think .NET 8 will change the question from ‘Which Flavor is better?’ to ‘How to mix different flavors to provide the best User Experience’.

Previous
Previous

Blazor Server Best Practices - Part 1

Next
Next

Lessons learned from PIM Implementation failures