Since you seem to have a positive sentiment towards Blazor, can you point me to a good introduction that demonstrates the power and the benefits of the framework, e.g. increased expressiveness, reduced friction, etc? I've looked through a couple of intros but they never seemed to really sell the benefits of it. As someone who loves the C# language and .NET ecosystem I really want to like it but nothing has clicked so far.
Attended a Blazor session at MS Build in May. My impression was, Blazor seems like a super cool tool that I will never be able to justify in production. For one, the performance is poor right now. Your options are either to use Signal to send every action over the network, or to deliver the entire .NET libraries along with the page. The size of that download is both impressively small (given the volume of code you're transferring), and also still way too large for me to feel comfortable foisting that on users.
Additionally, it requires that your front-end team feels comfortable working in .NET technologies. Ours certainly doesn't, and it would be very hard to sell my director on anything that doesn't maintain the traditional backend/frontend split.
The shared advantages are strong typing and compilation, C# code and constructs, Nuget ecosystem, and shared classes and logic between frontend/backend.
Client-side currently suffers from large download size and startup time (since the wasm .net runtime still interprets all the DLL files) on every run. It's still in preview so expect this to get better eventually. Client-side also still requires HTTP calls to the backend (since that's the only thing available in the browser) but you can use the `HttpClient` with all the shared classes and included JSON facilities instead of maintaining a separate version in JS.
Server-side means all the components run on the server, with updates and interactions run over SignalR websocket connection. This is best suited for internal apps, enterprise SaaS or other highly-interactive apps that would need a real-time connection anyway. The fact that all the UI logic runs on the server means you save a tremendous amount of effort by skipping all the view models, serialization, http calls, and everything else that's necessary. You can have database calls right in your component. This makes complex interactions incredibly easy. If you fit this scenario, Blazor is an fantastic tool compared to what we had before.
Also it's important to note that you don't need the whole app to be in Blazor. You can easily use MVC or Razor pages and just include an interactive component somewhere on the page. We use this for a normal server-rendered site that has some pages that require complex logic and just have that part powered by Blazor server-side as well. It's seamless and even supports server-prerendering so the first-load of the page is fully composed before the real-time connection starts up and takes over the state.
The idea is to unify the development process and tooling on the front-end and the back-end, without suffering from poor performance and constant unnecessary roundtrips over the network. Not to mention, a significant number of people strongly prefer C# to Javascript (and even Typescript).
If those two things never bothered you, then you might not understand the benefit, and you can continue to use what you like.
In practice, sending the .NET libraries over the network is the major burden of the approach Blazor takes, since the first load will be slow and bandwidth-intensive, even though everything will likely be cached for subsequent visits.
However, as the WASM tooling and standards improve, the library sizes will shrink, and less libraries in general will be necessary to accomplish stuff that has been solved at the level of web standards.
There is also server-side Blazor which doesn't use WASM components but instead uses SignalR to do client/server communication. Both are compatible with the same code base (and components). Server-side Blazor still has overhead but it's different from having to send the .NET libraries over the network.
Yes, sure. In my opinion, these are the main features:
1. You can have all the benefits of a static-strongly typed language such as C#. Which implies: better tooling, less prompt to type errors, and more suitable for enterprise software.
2. You get the full power of .NET in the browser
And, if you are already using ASP.NET for your backend:
3. You can reuse a lot of code. This means almost no class duplication (like when you work with TypeScript).
Extra:
4. Blazor is pretty similar to Angular +2, so the learning curve is smooth if you either have experience with Angular or C#.
I think the main benefit of Blazor (server side) is that it's very easy to write SPAs with it. This is great for incompany apps that don't have a lot of traffic (Blazor can be difficult to scale).
You bind your backend to your frontend and SignalR communicates all changes.
But there are some things you should be aware of. Because the frondend and backend are integrated it's very easy to 'leak' your data layer to the frontend. Always use viewmodels.
