Blazor

In this article, we are going to talk about what is Blazor, we will compare Blazor Server vs Blazor WebAssembly and show some pros and cons.

Usually, while developing a web application, we create a server-side project using Java, .NET, Node.js, or some other framework or language. We want to use that server-side project to show some data in a browser by using a JavaScript framework like Angular, React, or Vue.js. And this is just fine, moreover, it is a great solution.

But, we can’t use the language we used for the server-side application in the client-side application. So, there is a fundamental disconnect between these two.

So, wouldn’t it be great if we could use the same language for the server and client-side applications and reuse our knowledge? Well, we believe it would. We can achieve that by using WebAssembly. It is a native part of all the major browsers and it allows us to reuse our code from the server-side applications.

What is Blazor and Why Should We Use It?

Blazor is a free and open-source framework that allows us to build interactive web applications using C#. So, we can use C# to write both server and client code in Blazor. We achieve that by having .NET runtime compiled into the WebAssembly bytecode. The .NET runtime executes in the browser and can run any .NET DLL we provide to it, including the C# code that we create with our Blazor applications.

So, this is one of the reasons to use Blazor.

But there are more.

With the Blazor WebAssembly, we can run our applications in many major browsers without additional plugins. Furthermore, we can use any library we want, as long as it is compatible with the .NET standard. This means we can use the libraries we created and a large number of NuGet packages as well.

 Of course, performance plays a great role in choosing a framework for web development. That said, the ability to run Blazor in WebAssembly only proves the fact that it is pretty fast at almost native speed.

As we said, the Blazor application runs in WebAssembly, and WebAssembly runs in the JavaScript sandbox as any other JavaScript code. Because of this connection with JavaScript, our application can access the capabilities of the browser like web sockets, file API, and DOM. Additionally, our application can call the JavaScript code and vice versa.

 Currently, we have 4 hosting models for Blazor: 

• WebAssembly (web apps)
• Server (web apps)
• Hybrid (desktop & mobile apps)
• Mobile Blazor Bindings (experimental)

 The great thing? Components from the top three models are usually interchangeable. A component running in a Blazor WebAssembly app, can be lifted and run in a Blazor Hybrid application and vice versa (generally speaking). However, Mobile Blazor Bindings uses a different approach with components inspired from Xamarin Forms. This slight change of approach makes components written for the other hosting models incompatible with MBB.

 The Hosting Model Dilemma

 The problem that has been a thorn in the side of Blazor developers since almost the beginning: Which hosting model to pick. I’m specifically talking about building web applications now. Should it be WebAssembly or Server? What if I want to change further down the line? How much work would that be?

 Of course, as developers, we’re notorious for staking our claim and championing our chosen approach. Remember the age-old tabs vs. spaces feud? Yeah, same energy when it comes to hosting models!

The reality is that neither hosting model is perfect. Each of them have their pros and cons. Let’s take a look.

 Blazor Server

 The server hosting model has some very compelling advantages: 

Fast loading time - It delivers a small payload to the client containing only initial HTML and JavaScript and from that point forward all interactions are sent back to the server for processing with diffs returned to the client and applied to the DOM.

Code Security - All code stays on the server and away from prying eyes, it’s never downloaded to the client.

Full .NET Runtime - As a developer get access to the full .NET runtime. The application is running on the server and therefor you’re not subject to any restrains.

Development Speed - You don’t need a separate API project as you can connect to resources such as databases or file systems directly.

 However, it’s not all roses. There are trade-offs to picking this hosting model: 

Constant Network - It requires a stable connection between client and server. Even a small blip in the connection will result in the dreaded attempting reconnect overlay which makes the application impossible to use.

Network Latency - As all interactions are being processed on the server, they have to be sent from the client and a response awaited. If the client and the server are too far apart, this can result in perceivable lag for the user.

Cloud Costs - As this is a server based hosting model, all clients are connecting to the server. This means the more connections the application has, the higher the specs of the server and more it will cost.

 As you can see, there are some great pros, but the cons are not insignificant. Now let’s take a look at Blazor WebAssembly. 

Blazor WebAssembly

 Here are some of the advantages WebAssembly offers: 

Free Hosting* - It can be hosted for free as there is no need for a server based .NET runtime. Blazor WebAssembly apps can be run from places such as GitHub Pages, Netlify, Azure blob storage or Amazon S3 buckets.

Scalable - Following on from low hosting costs, is low scaling costs. Due to the app running entirely on the client, there can be little to no additional cost for on boarding more users.

Network Resilience - As it runs completely on the client, it also works well with unstable networks. By adding a service worker, Blazor WebAssembly apps can run as PWAs with very little effort. There is even a setting for this when creating a project.

 But there are some disadvantages: 

Download Size - It’s great that apps can run entirely on the client, but that does means that all the files need to be downloaded to the client in order to execute the application. This means the entire .NET runtime along with framework and application assemblies. Even on fast connections this results in a pause before the application comes to life.

Restricted Runtime - As the app is running in the browser, there are certain restrictions on how the runtime can execute. This means that instead of using JIT, which is the most common way .NET applications execute, Blazor WebAssembly uses an interpreter which is much slower, especially for CPU bound tasks.

Code Security - This isn’t so much an issue with the hosting model as an extra consideration for the developer. But as the entire application gets downloaded to the browser, dlls can be decompiled. Meaning that any sensitive logic needs to be put behind an API.

 As you can see, both hosting models have some fantastic advantages, but neither is without its compromises.

Wouldn’t it be marvellous if we could cherry-pick the best of both worlds? Imagine harnessing Blazor Server’s lightning speed and combining it with Blazor Web Assembly’s resilience. And here’s the twist: .NET 8 seems to be promising exactly that!

Full Stack Web UI with Blazor

.NET 8 is ushering in a new era where you won’t be boxed into a single hosting model. Think flexibility, modularity, and personalization. You can tailor how each page or even individual component renders. It’s like having your cake and eating it too!

Instead of committing to a single hosting model for your entire application, you can now mix and match based on the needs of specific pages or even individual components. For instance, a static contact page might use server-side rendering for performance, while a real-time dashboard might use the WebAssembly mode to leverage client-side capabilities. It’s all about giving developers the tools to make the best architectural decisions for each scenario.

How is all this going to be achieved I hear you ask, the answer is a new concept called render modes. Let’s explore each of them and see what they can do.

Server-side Rendering 

Channelling the power of traditional web apps, this mode is reminiscent of how Razor Pages or MVC applications function. Server-side rendering, or SSR, is when HTML is generated by the server in response to a request.

When using this mode, applications will load extremely fast as there is no work required on the client, and no large WebAssembly assets to download. The server is just sending HTML that the browser then renders. This also means that each request for a new page results in a full page load, as summarised in the illustration below.

At this point you might be asking what’s that point of this when Razor Pages and MVC already exist? That’s a good question, and the main reason is that neither of those frameworks offer a good story around building reusable components. Blazor has an excellent component model and this mode allows that to be leveraged for more traditional server-rendered sites.

I think another interesting angle to consider is that Microsoft are positioning Blazor as their preferred UI framework going forward. Over the last few versions of .NET, there’s been a lot of focus on making .NET more approachable to new generations of developers. Along this line, one criticism .NET has had is that there are so many options for doing things that it puts people off. This feel like an attempt to fix that. Learn Blazor and you’ll be able to build any type of UI, web (both static and dynamic sites), mobile, and desktop. It’s just a theory, but I think it has some legs.

Streaming Rendering

Think of this mode as the middle ground between server and client rendering. Let’s pretend we had a page in an applications that needed to make an async call to fetch some real-time data–either from a database or another API. If we used the SSR mode we just covered, that would mean having to wait for that async call to complete before returning any HTML to the client. This could result in a delay loading the page. Also, there isn’t any other interactivity in our page so using Server or WebAssembly mode would be a massive overkill. This is where streaming rendering comes in.

When using streaming rendering, the initial HTML for the page is generated server-side with placeholders for any content that is being fetched asynchronously. This initial response is then sent down to the browser to be rendered. However, the connection is kept open and when the async call completes, the remaining HTML is generated and sent down to the browser over the existing open connection. On the client, Blazor replaces the placeholder content with new HTML.

It’s all about enhancing the user experience by minimizing wait times.

Server Mode

While this retains the essence of the classic Blazor Server model, its granular application is the standout feature.

When selecting this mode a page, or component, will be optionally pre-rendered on the server and then made interactive on the client via a SignalR connection. Once interactive, all events on the client will be transmitted back to the server over the SignalR connection to be processed on the server. Any updates required to the DOM will then be packaged up and sent to the client over the same SignalR connection where a small Blazor runtime will patch the updates into the DOM.

If you’ve been working with Blazor for a while, none of this is new, except that you’ll now be able to decide this on a page by page or component by component basis!

WebAssembly Mode

The OG traditional SPA approach. This model is derived from the Blazor WebAssembly hosting model and fully capitalises on client-side capabilities, allowing C# code to run in the user’s browser.

Using the same example as Server mode, the stock prices page would be downloaded to the client along with the various framework DLLs and WebAssembly runtime. Once on the client, it would be bootstrapped and the page loaded. Any API calls to get data would be made and the UI would be re-rendered as necessary to display any data returned.

One thing to note about any components marked as RenderMode.WebAssembly is that they need to be referenced in a separate Blazor WebAssembly project to the main Blazor Web project. This is so that the framework can determine what code and dependencies need to be sent down to the client. If you want a component to run on both the server and the client, then the component should be placed in a Razor Class Library project that is references from the main Blazor Web project and the Blazor WebAssembly project.

Auto Mode

If there were an MVP among the rendering modes, this might just be it.

Since the early days of Blazor, developers have been asking for a way to combine the benefits of Blazor Server and Blazor WebAssembly. And with .NET 8 that request will become a reality. When setting a page or component to use Auto mode, the initial load of that component will be via server mode making it super-fast. But in the background Blazor will download the necessary assets to the client so that on the next load it can be done using WebAssembly mode.

 

 

While this rendering mode will address the biggest pain point for developers when embarking on a new Blazor project, what hosting model should we use? There are no free lunches.

Auto mode will increases the complexity of applications. Every component marked with RenderMode.Auto will need to execute on both the server and the client. Meaning that there will need to be some form of abstraction in place if the component needs to fetch any data.

 Conclusion

So, that is all for this introduction part of the Blazor series.

You have learned about Blazor, about different hosting models.

Also in this post, we’ve taken a first look at the major change coming to Blazor in .NET 8: Full stack web UI. Full stack web UI represents the biggest shift in the Blazor eco-system since the introduction of hosting models and is set to position Blazor as the “go to UI framework” for modern web applications built with .NET.

The new render modes give developers a huge amount of flexibility with their applications. We’ll be able to control how our applications are rendered at a per-component level. And Auto mode addresses one of the major pain points for developers getting started with new Blazor projects. But it’s not all sunshine and rainbows.

With great power comes great responsibility. Potentially having multiple render modes per page will create additional cognitive load for developers. If using Auto mode, developers will have to write server based code for fetching data, as well as traditional APIs as components will be run on both the client and server.