I'm confused whats different between Razor components and Blazor and which is better and in the last release .NET Core 3.0 Preview 3 the add those to Razor Components
Razor Components improvements:
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.
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.
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...
You have every right to be confused, the naming has changed a lot and when you wrote the original question the Blazor team had recently renamed 'Server Side Blazor' as 'Razor Components'. That has thankfully since been abandoned, see the timeline below for more on that.
To anyone finding that the naming conventions in the answers here don't seem to marry up with what they are reading in older blog posts it's worth knowing that the meaning of 'Razor Components' has changed repeatedly over time.
This may also help anyone like me who has been using Blazor since near the beginning and feels sure that the names have changed!
The naming has evolved a lot during the pre-release period. Kudos to the Microsoft and the Blazor team for trying to come up with clear names and being willing to change back when needed. However, this has left a legacy of mixed naming conventions in older articles and some Blazor veterans sometimes use older naming conventions.
At the time of writing in September 2020, with Blazor at version 3.2, the official naming convention is:
When Blazor 0.6.0 was released it was decided to officially name server side Blazor as 'Razor Components'.
Dan Roth discusses that in his Blazor 0.6.0 experimental release now available blog post in October 2018:
We announced last month at .NET Conf that we've decided to move forward with shipping the Blazor server-side model as part of ASP.NET Core in .NET Core 3.0. About half of Blazor users have indicated they would use the Blazor server-side model, and shipping it in .NET Core 3.0 will make it available for production use. As part of integrating the Blazor component model into the ASP.NET Core we've decided to give it a new name to differentiate it from the ability to run .NET in the browser: Razor Components.
It's also discussed more in the ASP.NET Core updates in .NET Core 3.0 Preview 2 blog post.
Probably due to confusion that was arising, the Razor Components name for Server Side Blazor was expanded to 'ASP.NET Core Razor Components'. This is mentioned in the Blazor 0.8.0 release notes:
Server-side Blazor is now ASP.NET Core Razor Components in .NET Core 3.0 As was recently announced, server-side Blazor is now shipping as ASP.NET Core Razor Components in .NET Core 3.0. We've integrated the Blazor component model into ASP.NET Core 3.0 and renamed it to Razor Components. Blazor 0.8.0 is now built on Razor Components and enables you to host Razor Components in the browser on WebAssembly.
In April 2019 Blazor server side went into official preview and as part of that the naming for server side Blazor was switched back:
Simplifying the naming and versioning
For a while, we’ve used the terminology Razor Components in some cases, and Blazor in other cases. This has proven to be confusing, so following a lot of community feedback, we’ve decided to drop the name ASP.NET Core Razor Components, and return to the name Server-side Blazor instead.
This emphasizes that Blazor is a single client app model with multiple hosting models:
- Server-side Blazor runs on the server via SignalR
- Client-side Blazor runs client-side on WebAssembly
… but either way, it’s the same programming model. The same Blazor components can be hosted in both environments.
Note that in the above description there is no mention of Razor Components at all, now we have two different Blazor hosting models (Client-side and server-side) as ways of delivering Blazor Components to the browser.
Dan Roth's Blazor and .NET Core release notes for the next few versions no longer mention the term 'Razor Components' at all until .NET Core 3.0 Preview 9 when the term emerges again in the name of the 'Razor component unit test framework prototype'.
By the time we get to May 2020 Razor Components and Blazor Components are now being used as synonyms for each other and the naming for the two hosting models has evolved.
The Blazor WebAssembly 3.2.0 now available blog describes that as follows (my emphasis):
Blazor components can then be hosted in different ways to create your web app. The first supported way is called Blazor Server. In a Blazor Server app, the components run on the server using .NET Core.
And...
Blazor WebAssembly is now the second supported way to host your Blazor components: client-side in the browser using a WebAssembly-based .NET runtime.
It would be so much easier if it was.. it does seem like 'Blazor Component' would be a more natural fit. But no, from the Components section of the official documentation:
Components in Blazor are formally referred to as Razor components.
