[Blazor SS Question] Advantage of Blazor SS over ASP razor page?

[BenHayat]

What are the main advantages in using Blazor Server Side over using ASP.Net Core Razor pages?

Structurally and functionally when I look at both, they both seem to be the same (some changes to routing and where code gets written) but as far using EF, building pages, serving them to user seem the same. In fact Razor pages offer powerful Taghelpers that Blazor doesn't and razor pages are mature and solid.
So why should I use Blazor for future project than good old MVC or Razor pages. This question is only for Blazor Server Side and not client side.

Thank you in advance!
..Ben

[Andrzej-W]

Short answer: use Blazor Server Side if you want to create interactive application and write your code in C#.

Blazor template contains Counter component. Try to implement this in Razor pages or MVC without JavaScript or full page refresh.

Another example. Let's assume you have two combo boxes. First contains a list of countries. Second should contain cities in selected country. The same suggestion as above: try to implement this in Razor pages or MVC without JavaScript or full page refresh.

Try to create any complex LOB (Line of Business) application where you have to implement interactive invoice entry form. Application have to recalculate everything after each change (amount, price, discount, etc.). Tax regulations are complex (at least in Europe) and you need more than 1000 lines of code to handle all edge cases. In Razor pages/MVC application if you want to have interactive application you have to implement business logic in JavaScript and duplicate the same rules in C# to validate (recalculate) invoice on the server. This is very complex task. In Blazor you can implement your business logic in C# and it is enough. Take into account one more fact. In JavaScript there is no decimal data type. If you want to correctly calculate an invoice you have to fight with rounding errors all the time (and of course there are many rounding rules you have to use).

[BenHayat]

@Andrzej-W ;
I thank you for the time you took to respond. As I had written SPA app before I fully agree the benefits of "Interactivity" that Blazor gives us. And your cascading combo box example also makes sense, that I have to use jQuery Ajax.
As I'm following the growth of Blazor and see how many stuff needs to be completed and become stable, it gives me that cold sweat that Blazor is going to takelong time to become as stable of MVC or Razor pages, and I don't have that TIME to wait, before writing and putting a product into production. My product has to be live before the end of the year. That's why I want to know what else will I be missing IF I go with Razor pages.
Thanks!

[3x0dv5]

"My product has to be live before the end of the year." That's key. Honestly I'd go with Razor Pages. Blazor server side has to keep those signalr connections open, so if your app is going to have a lot of visitors that could take a toll on your servers.
Blazor client side, I'd say is far from being useful in a production setting, in particular with the initial load of assemblies (several MB), and if you have in your team careless developers you can expect to have an assembly that was suppose to only be used server side to leak to the client side increasing the size and even possibly represent a security risk to your application.

[Andrzej-W]

That's why I want to know what else will I be missing IF I go with Razor pages.

Let's assume you have to implement some complex algorithm which is necessary to make your page interactive. In Razor pages you have to write it in JavaScript. In Blazor you can write it in C#, and because it works on the server you can use any .NET library which is compatible with .NET Standard. If you implement your code in JavaScript everybody can see it, debug it, clone it, etc. Code on the server is safe - nobody have access to it.

You also have to take into account some limitations of Blazor Server Side. All events are asynchronous. That is often the big problem - read #5545. To implement some functions you will need JavaScript no matter what. If you want to have good SEO and integration with social media you will have some problems in Blazor - read #9128.

My product has to be live before the end of the year.

If your project does not require to much interactivity and you are comfortable with JavaScript you should probably create it in Razor pages or MVC.

[BenHayat]

@3x0dv5 & @Andrzej-W ;

Thank you for your feedback. Digging deeper over the weekend in Asp Razor pages, one thing became very clear to me. Razor Pages are very well thought out and a "complete" platform, in some ways even better and cleaner than MVC.
This app doesn't require direct interaction like the app I wrote in Vue. However, I wonder if we can make the index.cshtml (as the defaut page) to be a a "PWA" app. for the mobile?

[3x0dv5]

I've never done it, but can't see why not. In practically terms the browser doesnt know anything about the cshtml, the browser will only be concerned with the paths that you put in the @page directive.

In a PWA using client side blazor you will have a list of files to cache like:

var filesToCache = [
    './',
    // Html and css files
    './index.html',
    './css/site.css',
    './css/bootstrap/bootstrap.min.css',
    './css/open-iconic/font/css/open-iconic-bootstrap.min.css',
    './css/open-iconic/font/fonts/open-iconic.woff',

    // Blazor framework
    './_framework/wasm/mono.js',
    './_framework/wasm/mono.wasm',
    './_framework/blazor.boot.json',
    './_framework/blazor.webassembly.js',

    // Our additional files
    './favicon.ico',
    './manifest.json',
    './serviceworker.js',
    './icons/icon-192x192.png',
    './icons/icon-512x512.png',

    // The web assembly/.net dll's
    './_framework/_bin/Microsoft.AspNetCore.Blazor.dll',
    './_framework/_bin/Microsoft.AspNetCore.Components.Browser.dll',
    './_framework/_bin/Microsoft.AspNetCore.Components.dll',
    './_framework/_bin/Microsoft.Extensions.DependencyInjection.Abstractions.dll',
    './_framework/_bin/Microsoft.Extensions.DependencyInjection.dll',
    './_framework/_bin/Microsoft.JSInterop.dll',
    './_framework/_bin/Mono.Security.dll',
    './_framework/_bin/Mono.WebAssembly.Interop.dll',
    './_framework/_bin/mscorlib.dll',
    './_framework/_bin/System.ComponentModel.Annotations.dll',
    './_framework/_bin/System.Core.dll',
    './_framework/_bin/System.dll',
    './_framework/_bin/System.Net.Http.dll',

    //The compiled project .dll's
    './_framework/_bin/App.Test.BzCl.dll'

But in your Razor pages you'll have urls that you might specify on the @page, like

@page "/app-admin/add-user"
@model App.Pages.Admin.AddUser
@{
    Layout = "_Layout";
}

so in your filesToCache you will want to add ./app-admin/add-user, now keep in mind that this add user could potentially be accessed offline, you need to handle the "saving" of the info offline and sync when you go back online. (Maybe the add user example was a really bad one though, but you get the idea).
For the index.cshtml you add to the cache the './' and you can change the @page to @page "index.html" and cache ./index.html.

Razor pages might come short for a PWA when dealing with offline and submitting the data to the server once back online, for read only pages might work fine but dealing with scenarios to submit data to the server, let's say a messaging system, you may need to write some javascript to deal with it because you will want to keep the data in local cache and automatically submit it to the server once the app is back online. Don't know if makes sense... in short a PWA has plenty of client side logic.
As I said, I never done it, and I might be totally wrong.

[BenHayat]

@3x0dv5 ;
Thanks for the comment. In Razor Pages model, I would not incorporate "offline" at all. My primary goal of using PWA, would be:
A) An easy way for user to install the App's URL on her mobile page
B) Ability to run "Service Worker"as a background task to check with Server's Web API for data change, when the app is not active on Mobile.

[3x0dv5]

in that case shouldn't be a problem. Add the manifest.json, icons, and cache a few files to at least show that the app is offline and you can even test it on chrome on your lap/desktop. When you provide the manifest.json chrome will show a "Install {app name}..." on the menu

and then you can see the app icon on your desktop (at least on Windows 10)

[BenHayat]

@3x0dv5
Thank you for your great info. Much appreciated!

[stavroskasidis]

You don't have to limit yourself. You can start with razor pages or mvc and when core 3.0 comes out, you can start gradually and at your own pace integrate components in your existing razor pages or mvc views.