[ACCEPTED]-Asp.net core blazor vs .net core mvc with razor-blazor

Accepted answer
Score: 107

0 Video with visual explanation

enter image description here

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

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

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

To illustrate 166 this, let's say you have a list of articles 165 (for example blog posts) showing a preview. When 164 the user clicks on read all, you usually have two 163 ways to realize this in traditional web 162 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 161 are not interactive. This means: After the 160 page is loaded and rendered, nothing happens 159 any more – except the user load another 158 page (with the entire DOM) by clicking on 157 a link – for that reason, it’s called „multi-page“ application.

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

If you like traditional 147 pages to be interactive, you need JavaScript. For 146 example you can add an ajax call to some 145 API that displays some data when the user 144 clicks a button, without having to reload the entire 143 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 142 of a full rendered html page. If you navigate 141 there like by clicking on article, they 140 load a JavaScript application. It handles 139 everything interactive there. If the user 138 clicks on an article, there is NO complete 137 HTML document fetched from the server! Instead, it 136 only fetches the parts who are changed, in 135 this case the article. Everything else (e.g. navigation 134 bar, footer, widgets etc) will remain - in 133 opposite th multi-page apps, where this 132 may be reloaded if no js/ajax is used.

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

For the user, a SPA normally 120 is much faster than navigating through pages 119 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 118 is a SPA. But the main difference to other 117 frameworks is, that Blazor lets you control 116 both the client and server side with C# code. To 115 show that benefit, let's look at other SPA 114 frameworks like Angular: You can build an 113 Angular SPA with ASP.NET Core. In this case, you 112 write your client side in Angular with TypeScript. If 111 you need to access data, it will make API 110 calls to the ASP.NET Core server, which 109 is C#. It will be similar with other frameworks 108 like React, but here with JavaScript instead 107 of TypeScript.

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

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

3.1 Blazor WebAssembly and Blazor Server

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

Blazor WebAssembly

enter image description here

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

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

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

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

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

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

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

Blazor Server

enter image description here

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

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

What to choose?

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

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

But in this case, you can migrate later!

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

Further information

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

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

More Related questions