Razor components vs Blazor

Razor Components is a framework with which you can create SPA web applications. It is divided into two mode of execution. When the web app is hosted and executed on the browser, it is called Blazor. Blazor applications are written in C# and compiled into .NET assemblies. They are executed and run on the browser as .NET assemblies by the Mono run time, which itself is compiled to Web Assembly.

The second mode of execution is server-side. That is, your web app is executed on the server, not on the browser. Note that here the runtime environment is not Mono Web Assembly but the Asp.net Core run time. This is called server-side Blazor, but the term Razor Components is used as well, so that the confused get perplexed. The reason for this is historic: At the beginning, there was only Blazor running on the browser. But then came the idea that a web app can run on the server, and only the diffs can be send to the browser by means of SignalR. Running the web app on the server is much easier than running on the browser, and the developer can use many elements he can't use on the browser, such as debugging, etc. As a result of this possibility, the Asp.Net renamed the Blazor framework as Razor Components, which you can treat as a super structure on which Blazor is built. This is why the confusion. Let's emphasize this division as follows:

Razor Components --> Blazor (front end; browser)

Razor Components --> Razor Components (server-side Blazor )

I know this is a source of confusion, but this is it...

As to the question which is better, I may only say that it depends exclusively on your requirements. Each of these mode of executions has its benefits and drawbacks. Blazor applications are more suitable for running on the internet as public web sites, whereas server-side Blazor application are best used on the Intranet as enterprise web sites.

The list you displayed is related to Razor Components framework. Some improvements, for the time being, may only be relevant to Blazor, others to server-side Blazor. There is only one way to know which is which: To learn Razor Components. It takes time to learn it, less than Angular, especially if you are a .Net developer, but it is still something which requires some investment.

Hope this helps... I'll improve on it later on, but if you have specific question don't hesitate to ask...

Essentially there are 3 parts to understand.

Razor Components

This is the name for the core, out of process, component model which was created back in July 2018, for the first release of Server-side Blazor.

Razor Components is the core of the framework and contains all the following things.

• Parameters
• Event handling
• Data binding
• Routing
• Dependency injection
• Layouts
• Templating
• Cascading values

Server-side Blazor

This is the server-side hosting model, running on ASP.NET Core, for Razor Components. This version hosts the Razor Components model on the server. It uses a small runtime to send UI events from the browser to the server. Once processed by Razor Components, any UI updates get sent back from the server to the browser and the runtime handles updating the DOM. All this communication is handled via a SignalR connection. Even JS interop calls are handled this way.

Client-side Blazor

This is the client-side hosting model for Razor Components.

In this model, everything is hosted in the browser. Mono, compiled to WebAssembly, is the .NET runtime. On top of this sits Razor Components and then finally the application.

The great thing about this architecture is that any feature added to Razor Components should, in theory, be available to both hosting models. Although in reality, this is not always the case.

What's better?

That very much depends on what you want to do.

Client-side Blazors biggest drawback is its download size. This alone could rule it out for many developers. Downloads are easily into multiple MBs which if someone is trying to view your app on a mobile with a slow connection, they are not going to have a great experience. However, it's worth noting that after the first download a lot of the content is cached so subsequent loads can be a few 100kb.

Client-side Blazors debugging experience is very primitive right now as well. Which means working on it as a developer can be challenging at times.

Server-side Blazor has a much nicer developer experience in terms of debugging. The app is much faster to download and only has a size of a few 100kb before any caching takes place.

The downside is potentially scalability. But this will very much depend on the number of concurrent users you are expecting. Because this model uses SignalR your app will have a top limit on concurrent connections. But, you can manage this by plugging into Azure SignalR to allow a far greater number of connections to your app.

Ultimately, both hosting models of Razor Components have a long way to go. The authentication stories for both are in very early days, although client-side Blazor is arguably in a better place. The routing engine is still limited, forms and validation have only just had it's first release and there is still work to do.

Another thing to keep in mind is that it is possible to swap between the models pretty easily. So whatever decision you make you're not tied into it. There will even be a way of doing this built into the framework at some point so nothing you do now will be wasted.

Any questions, please ask. But I hope this helps.