Difference between "Web Application" and "Blazor Server App" in ASP.NET core 3.1

The WebApplication uses .NetCore and Razor pages to create web pages and ordinary HTTP requests to communicate between a server and a client. You still need JavaScript as before to call a method for instance, and communicate between the view and models/methods and also to update/refresh the view. it is almost stateless and you need to follow the traditional approaches as we do for ASP.Net MVC.

The Blazor on the other hand, has two versions. WebAssembly and Server-side.

1. The "Blazor WebAssembly" runs over WASM (WebAssembly) and MONO on the client-side and the code will be downloaded on the client and well, it brings some fancy features and possibilities like offline-mode. But almost everything will be downloaded on the client which makes the first load a bit slower and also think about downloading your code on the client directly.
2. "Blazor Server-Side" which runs on a server but the client will be updated simultaneously over a SignalR connection. Thus, a smaller amount of data should be downloaded on the client and also the code is not there (regarding the security aspects) and also it is stateful, which means every state of the elements on the client will be kept on the Server memory and also in any case if the client loses the connection, the whole page state will be unknown for the new server. (you need custom approaches to keep the state using localStorage and sessionStorage and map that to the new server after establishing a new connection).

By using Blazor, you can almost do everything using C# for Backend and Frontend and bearly need to use JS. Although it is possible to call JS functions (using JSIntrop) from C# code and even call a C# function from JS.

I hope this short explanation will be helpful. This only a brief intro over .NetCore WebApplication and Blazor. there are a lot of aspects that a developer should take care of them for choosing a decent approach for building a web application.

I have gone through an article, It has very easily described the differences between these two with their Pros and Cons.

Blazor WebAssembly hosting model benefits:

• A Blazor WebAssembly app can run entirely on the client machine. So, after the application is downloaded, a connection to the server is not required. This means there is no need for your server to be up and running 24X7.
• Work is offloaded from the server to the client. It is the client resources and capabilities that are being used.
• We do not need a full-blown ASP.NET Core webserver to host the application. We just need a server somewhere, that can deliver the application to the client browser. This means we can host the application on our own server on the internet somewhere, in the cloud, on Azure as a static website or even on a CDN Content Delivery Network.

Downsides of Blazor WebAssembly hosting:

• The very first request usually takes longer as the entire app, its dependencies and the .NET runtime must be downloaded to the client browser. Keep in mind, it's only the first request that takes longer than usual. If that same client visits the application later, it usually starts fast because the browser caches the files.
• Since the app runs entirely on the client browser, it is restricted to the capabilities of the browser.
• Depending on the nature of the application, capable client hardware and software is required. From a software standpoint, for example, at least a browser with WebAssembly support is required.

Blazor Server hosting model benefits:

• The app loads much faster as the download size is significantly smaller than a Blazor WebAssembly app Since the app runs on the server, it can take full advantage of server capabilities, including the use of any .NET Core compatible APIs.
• All the client needs, to use the app is a browser. Even browsers that don't support WebAssembly can be used.
• More secure because the app's .NET/C# code isn't served to clients.

Downsides of Blazor Server hosting:

• A full-blown ASP.NET Core server is required to host the application. Serverless deployment scenarios such as serving the app from a CDN aren't possible.

• An active connection to the server is always required. This means there is a need to keep the server up and running 24X7. If the server is down, the application stops working. As every user interaction involves a round trip to the server a higher latency usually exists when compared with Blazor WebAssembly hosting.

• Scalability can be challenging especially for the apps that have many users as the server must manage multiple client connections and handle client state. However, we can overcome this scalability issue, by using Azure SignalR Service with a Blazor Server app. This service allows a Blazor Server app to scale really well by supporting a large number of concurrent SignalR connections.

Reference: https://www.pragimtech.com/blog/blazor/blazor-hosting-models/

A Blazor Server app has JavaScript running on client and all the interactions are passed via SignalR back and forth between client and server.

The Web Application template sets up a Razor Pages project. Though they both use Razor as a templating engine to generate HTML, a Razor Pages project is much more similar to MVC, but without the controllers. Communication between client and server side is based on traditional HTTP requests. Client to server communication is done based on form posts, and the server will just respond with HTML rendered from a view. If you need interactivity on the client side, you'll need to use JavaScript to accomplish it.