I would recommend starting with the server-side variant of Blazor on a non-production test app to familiarize yourself. You can easily move to client-side WASM mode once you need to (or feel comfortable doing so) without any major changes to your codebase.
Our long term plans (aka by end of 2020) are to rewrite all of our internal tooling from SPA (RiotJS) w/ JSON APIs to server-side Blazor. The principal motivations here are productivity gains. It is a LOT faster to write a razor view in C# with direct invocation of your business logic from view logic, than it is to determine what a clean JSON API contract looks like, write all the boilerplate for controllers, and then play the back-and-forth game between chrome devtools and visual studio with 2 separate debugging contexts. After you write your first LINQ .Where().Select() to populate a table in Blazor, you will truly understand what I am getting at in terms of productivity if you have ever tried to do the same sort of filter->map stuff in JS.
With Blazor, I only need to know C#, HTML, CSS and just enough JS to write a blazorhelper.js interop which reads and writes my session cookies. I set 1 breakpoint in visual studio and it gets hit when I press some button in the browser.
With SPA, I have to be at the top of my JS game, and also pull some SPA framework into my mental context which must then be shared with all of the other C# business logic in scope. I have to manage breakpoints in the browser as well as in visual studio. I have to deal with 10-100x the amount of JS code.
Additionally, we don't even want to move to client-side variants of Blazor for our use case. First request latency and security are the 2 largest motivators for us here. Server-side exposes precisely zero things to the client you didn't want to, as opposed to SPA which makes even unauthenticated clients download your entire application. Also, "the server" is substantially faster these days (even more so going into 2020 on AMD's warpath). For the number of concurrent clients we are anticipating, server-side Blazor is actually our best option in terms of UX.
I would be curious what aspect of Blazor feels immature to you. It is certainly a new(ish) thing, but the fundamental aspects of it (especially server-side mode) have been around for decades and microsoft has leveraged a lot of existing or otherwise proven ideas here. I would agree on the client-side aspect being "immature" relative to server-side, mostly due to WASM and the need to push a very large payload to the client upon first request.
I absolutely see the benefits of using Blazor. But it feels immature because I see a lot of tutorials with ways to work around little bugs and problems.
But orcourse those tutorials could be from before the official launch which was just some months ago.
I think Blazor looks a little like Phoenix Live View. And imho this is the way to go. It is way more productive for the reasons you describe as well.
Our long term plans (aka by end of 2020) are to rewrite all of our internal tooling from SPA (RiotJS) w/ JSON APIs to server-side Blazor. The principal motivations here are productivity gains. It is a LOT faster to write a razor view in C# with direct invocation of your business logic from view logic, than it is to determine what a clean JSON API contract looks like, write all the boilerplate for controllers, and then play the back-and-forth game between chrome devtools and visual studio with 2 separate debugging contexts. After you write your first LINQ .Where().Select() to populate a table in Blazor, you will truly understand what I am getting at in terms of productivity if you have ever tried to do the same sort of filter->map stuff in JS.
With Blazor, I only need to know C#, HTML, CSS and just enough JS to write a blazorhelper.js interop which reads and writes my session cookies. I set 1 breakpoint in visual studio and it gets hit when I press some button in the browser.
With SPA, I have to be at the top of my JS game, and also pull some SPA framework into my mental context which must then be shared with all of the other C# business logic in scope. I have to manage breakpoints in the browser as well as in visual studio. I have to deal with 10-100x the amount of JS code.
Additionally, we don't even want to move to client-side variants of Blazor for our use case. First request latency and security are the 2 largest motivators for us here. Server-side exposes precisely zero things to the client you didn't want to, as opposed to SPA which makes even unauthenticated clients download your entire application. Also, "the server" is substantially faster these days (even more so going into 2020 on AMD's warpath). For the number of concurrent clients we are anticipating, server-side Blazor is actually our best option in terms of UX.
I would be curious what aspect of Blazor feels immature to you. It is certainly a new(ish) thing, but the fundamental aspects of it (especially server-side mode) have been around for decades and microsoft has leveraged a lot of existing or otherwise proven ideas here. I would agree on the client-side aspect being "immature" relative to server-side, mostly due to WASM and the need to push a very large payload to the client upon first request.