Asp.net core blazor vs .net core mvc with razor

Question

What is the archtecture difference between working with razor vs blazor?

Documentation suggest that I have to write an Web Api when using blazor - is it still possible to pass model objects like in traditional razor ?

Answer 1

0 Video with visual explanation

I decided to make a video, since several questions about Blazor were asked (also on other forums) and this format seems much better for me to visualize the differences - instead of reding my (longer) explanation. The video contains a bit improved version, compared to my first post (the text post is also updated) It's one of my first videos in this format, so any feedback is welcome. If you prefer to read a classic text without much visualization, you'll find it's content in the following sections. Of course without the demos, which I made to lighten the content up, but the basic information content is the same.

1. What is a traditional multi-page site or application?

First you need to have a basic understanding how traditional websites/apps works: For every call/request, you send a request to the server and the server responds with the complete HTML of the entire page. This can be dynamically generated like with ASP.NET Core MVC and Razor templates or Razor Pages or even some other technique like PHP, Java, Python and so on. Let's say you have a list of articles showing a preview.

To illustrate this, let's say you have a list of articles (for example blog posts) showing a preview. When the user clicks on read all, you usually have two ways to realize this in traditional web apps:

1. Load a page like /view-article?id=123 where the above happens again: Loading the entire HTML DOM of the article page
2. Using JavaScript to make an Ajax-Request, which loads the desired content from an API like /api/get-article?id=123 and manipulate the DOM to display it at the desired position

Without JavaScript, traditional sites are not interactive. This means: After the page is loaded and rendered, nothing happens any more – except the user load another page (with the entire DOM) by clicking on a link – for that reason, it’s called „multi-page“ application.

You'll propably prefer the second approach, cause it's faster and saves ressources: Instead of rendering the entire page again (where only a part of it has changed), you stay on that page and just load the new information you need (the article content in this example). Especially on large pages with many ressources to load and render, the JavaScript approach feels much faster to the user.

If you like traditional pages to be interactive, you need JavaScript. For example you can add an ajax call to some API that displays some data when the user clicks a button, without having to reload the entire page.

In short we can say, that most of the work happens here on the server side.

2. Where is the difference to single-page applications (SPA)?

SPAs have just a single page, in terms of a full rendered html page. If you navigate there like by clicking on article, they load a JavaScript application. It handles everything interactive there. If the user clicks on an article, there is NO complete HTML document fetched from the server! Instead, it only fetches the parts who are changed, in this case the article. Everything else (e.g. navigation bar, footer, widgets etc) will remain - in opposite th multi-page apps, where this may be reloaded if no js/ajax is used.

You often have modulary components there and two-way data binding. This means, a variable is linked to some HTML element. When the variable changes, the element automatically displays the new value. In traditional apps, you'd have to create event handlers manually to handle this. It can be seen as continued development of a single page application with vanilla JavaScript, where you need more manual work to archive things like data-binding.

For the user, a SPA normally is much faster than navigating through pages on multi-page apps.

In short we can say, that most of the work happens here on the client side in the browser of the user. The server just serves static stuff (html, js, css) and provides APIs for e.g. fetching entries from the DB or save them.

3. What has Blazor to do with that?

A Blazor app actually is a SPA. But the main difference to other frameworks is, that Blazor lets you control both the client and server side with C# code. To show that benefit, let's look at other SPA frameworks like Angular: You can build an Angular SPA with ASP.NET Core. In this case, you write your client side in Angular with TypeScript. If you need to access data, it will make API calls to the ASP.NET Core server, which is C#. It will be similar with other frameworks like React, but here with JavaScript instead of TypeScript.

This make it hard to share code between those two: If you have an article model, it needs to be defined in C# on the server and in TypeScript on the client as well. With Blazor you just define it once in C# and re-use it on both sites. In other words: You just write C# without having to care about JavaScript*

*That’s the basic idea behind Blazor: Use C# everywhere, without the need for JavaScript as second technology. But it’s worth mentioning that you need to work with Blazor components to accomplish this. If you need some library not being ported to Blazor yet, you still have to handle a bit of JS. However, there are still benefits like the data binding. Using it on an entire plain JS stack would be some work, so I’d recommend to start with an UI library that offers Blazor components.

3.1 Blazor WebAssembly and Blazor Server

Now you know the basics and you need to decide between two flavours:

Blazor WebAssembly

As the name suggests, it basically uses WebAssembly to run your C# browser directly in the browser. It requires a relatively recent Browser and is not yet supported on all platforms/browsers. Also major engines like Chromium or Safari doesn't support all standardized features yet.

Let's say you have a button with C# code as handler like this:

 <button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

IncrementCount is a C# method. The code got transfered to the client and would be executed in the browser. Imagine it as .NET Core runtime inside the browser, like Silverlight BUT without any external plugins. There is no need to even have ASP.NET Core on the server-side! It can be served from any webserver, as long as you don't need things like DBs from the server side. This makes the app larger (and slower, at least on the first load).

The example Visual Studio template has a size of more than 17 Megabyte! With compression this can be reduced to 7 Megabyte – still a lot for a hello world application. By publishing the application in release mode, this goes down to about 7 MB and 2.4 MB with gzip. At least subsequent requests are faster. Those DLL files are stored in the browser cache, which avoids further requests. But it can be used offline (at least the main logic without API calls). For that reason, it's sometimes called real SPA – it’s compareable to Angular, React and other client-side frameworks. Because of the WebAssembly-Usage, Debugging can be harder here, currently it just support Chromium based browsers.

Don’t know WebAssembly? It’s a relatively new, open standard that generates bytecode to improve loading and execution time to realize more powerfull web-applications – independent of the language. You’re not forced to use specific languages like JavaScript: Since Bytecode is generated, also other languages like C++ or Rust can be used.

In a nutshell, WebAssembly can be seen as next generation JavaScript for feature-rich webapps, where Blazor WebAssembly is the C# implementation. Because of the browser runtime, there are some APIs which can’t be used here. For example sockets or I/O access, like File.Open or File.Write.

Blazor Server

The app runs on the server and just transfers the output (like the result of a click event, that increases some counter in another HTML element) to the browser using SignalR Websockets. This makes the app smaller and faster, but requires more ressources on the server-side cause you have a SignalR connection and it's virtual DOM also on your server - making it harder to scale in large setups.

On the other side, this reduces the requirements on the clients: They don't need to support WASM, so it could run on older browsers or browsers with restricted WASM support as well as low-end devices. But since every action ends in a SignalR call, the app won't work offline - if this is a requirement, choose Blazor WebAssembly over Blazor Server.

What to choose?

It depends on your needs, as pointed out above. For example, if you need offline support, Blazor server wouldn't be a good choice. If you're unsure I'd prefer Blazor Server and only really worry about this if you're planning to deploy a very large application.

Imho, Blazor server is currently smoother and more flexible. Blazor Server also got stable before WebAssembly. This recommendation may changes in the future, when WebAssembly has developed further and got more widely supported.

But in this case, you can migrate later!

Both Blazor WebAssembly and Server use Razor components. This means: You can change between both, without re-writing your entire code. Some migration work is only required for things like data-calls outside the browser when migrating from Blazor Server to Blazor WebAssembly. The reason is, that Blazor WASM runs entirely in the browser, so you need a server part like an ASP.NET Core API projekt to handle them.

Further information

I recommend the Introduction to ASP.NET Core Blazor in the official documentation. Also the other chapter describing a lot of information about the platform and offers tutorials. They go deepter in detail to topics like data binding or event-handling to just name a few, and illustrating them with examples. I tried to kept it shorter here for a basic overview.

See also: Blazor WebAssembly 3.2.0 and ASP.NET Core 5