Scott Hanselman

What is Blazor and what is Razor Components?

March 19, '19 Comments [31] Posted in ASP.NET | Javascript | Open Source
Sponsored By

I've blogged a little about Blazor, showing examples like Compiling C# to WASM with Mono and Blazor then Debugging .NET Source with Remote Debugging in Chrome DevTools as well as very early on asking questions like .NET and WebAssembly - Is this the future of the front-end?

Let's back up and level-set.

What is Blazor?

Blazor is a single-page app framework for building interactive client-side Web apps with .NET. Blazor uses open web standards without plugins or code transpilation. Blazor works in all modern web browsers, including mobile browsers.

You write C# in case of JavaScript, and you can use most of the .NET ecosystem of open source libraries. For the most part, if it's .NET Standard, it'll run in the browser. (Of course if you called a Windows API or a Linux specific API and it didn't exist in the client-side browser S world, it's not gonna work, but you get the idea).

The .NET code runs inside the context of WebAssembly. You're running "a .NET" inside your browser on the client-side with no plugins, no Silverlight, Java, Flash, just open web standards.

WebAssembly is a compact bytecode format optimized for fast download and maximum execution speed.

Here's a great diagram from the Blazor docs.

Blazor runs inside your browser, no plugins needed

Here's where it could get a little confusing. Blazor is the client-side hosting model for Razor Components. I can write Razor Components. I can host them on the server or host them on the client with Blazor.

You may have written Razor in the past in .cshtml files, or more recently in .razor files. You can create and share components using Razor - which is a mix of standard C# and standard HTML, and you can host these Razor Components on either the client or the server.

In this diagram from the docs you can see that the Razor Components are running on the Server and SignalR (over Web Sockets, etc) is remoting them and updating the DOM on the client. This doesn't require Web Assembly on the client, the .NET code runs in the .NET Core CLR (Common Language Runtime) and has full compatibility - you can do anything you'd like as you are not longer limited by the browser's sandbox.

Here's Razor Components running on the server

Per the docs:

Razor Components decouples component rendering logic from how UI updates are applied. ASP.NET Core Razor Components in .NET Core 3.0 adds support for hosting Razor Components on the server in an ASP.NET Core app. UI updates are handled over a SignalR connection.

Here's the canonical "click a button update some HTML" example.

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

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

@functions {
int currentCount = 0;

void IncrementCount()
{
currentCount++;
}
}

You can see this running entirely in the browser, with the C# .NET code running on the client side. .NET DLLs (assemblies) are downloaded and executed by the CLR that's been compiled into WASM and running entirely in the context of the browser.

Note also that I'm stopped at a BREAKPOINT in C# code, except the code is running in the browser and mapped back into JS/WASM world.

Debugging Razor Components on the Client Side

But if I host my app on the server as hosted Razor Components, the C# code runs entirely on the Server-side and the client-side DOM is updated over a SignalR link. Here I've clicked the button on the client side and hit the breakpoint on the server-side in Visual Studio. No there's no POST and no POST-back. This isn't WebForms - It's Razor Components. It's a SPA app written in C#, not JavaScript, and I can change the locations of the running logic, while the UI remains always standard HTML and CSS.

Debugging Razor Components on the Server Side

It's a pretty exciting time on the open web. There's a lot of great work happening in this space and I'm very interesting to see how frameworks like Razor Components/Blazor and Phoenix LiveView change (or don't) how we write apps for the web.


Sponsor: Manage GitHub Pull Requests right from the IDE with the latest JetBrains Rider. An integrated performance profiler on Windows comes to the rescue as well.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Friday, March 22, 2019 8:04:42 AM UTC
SPA only?
Matthew
Friday, March 22, 2019 11:02:37 AM UTC
From last couple of days i was planning to read about "Blazor", just saw your article.
Thanks! For such a nice article. I'm more interested to know about its practical use like what kind of applications can gain advantages from this framework?
medeveloper
Friday, March 22, 2019 11:52:56 AM UTC
I read a lot about Blazor but I always see the same example of the counter. We need more samples of more "real-life" projects. And I want to use this, ofc.
Óscar Vicente Pérez
Friday, March 22, 2019 11:58:05 AM UTC
I'm waiting for VS2019 to be released, given it's so only <2 weeks away now, but really looking forward to using Blazor. Liked the idea of Angular but if I can do stuff in C# then even better :)
Stephen Jones
Friday, March 22, 2019 3:27:48 PM UTC
<blockquote cite="chris>This doesn't require Web Assembly on the client, the .NET code runs in the .NET Core CLR (Common Language Runtime) and has full compatibility - you can do anything you'd like as you are not longer limited by the browser's sandbox.</blockquote>

I really can't see this as a good idea in any context.
Chris Wegener
Friday, March 22, 2019 4:15:32 PM UTC
Oscar check out the Blazing Pizza demo app for something more meaty [ahem]

https://aka.ms/blazorworkshop
Howard Richards
Friday, March 22, 2019 5:06:40 PM UTC
Chris - then it's probably not for you. But there's a ton of people excited about this - not just with C# but with Python, Elixir, Go, and a ton of other languages.
Friday, March 22, 2019 5:50:40 PM UTC
@Chris Why isn't a good idea? Without giving a reason, it just sounds like you're trying to spread FUD.

I see this as a great idea: C# is my preferred language. It has strong typing. I can share models and validation logic between client and server side. I can take advantage of a number of libraries that will run directly in .NET on the browser.
Friday, March 22, 2019 5:50:45 PM UTC
Hi,

i build app with razor components but always should clean solution and re build and re-run,
there is any solution?
Kardo Hussein
Friday, March 22, 2019 8:05:16 PM UTC
So, everything that was new again that was old is new again. It's the whole thin client / fat client cycle repeated yet again.

Client / Server

Terminal / Mainframe
Windows App / File Server
Citrix Client / App Server
Web Pages / Web Server
SPA / API Server
Blazor / API Server
Razor Client / Server Razor Components

Ain't this fun?



PilotBob
Saturday, March 23, 2019 6:12:57 AM UTC
I'm loving it!
rodrigo ratan
Sunday, March 24, 2019 10:23:37 PM UTC
Thanks for introducing me to this to Twitter earlier!

I have to admit I was skeptical at first, but I now see a lot of potential for this approach. Currently I think the biggest obstacle for the pure client side version is payload size, but maybe this will improve over time?

I ran a quick example myself here in case anyone is interested in checking it out. I basically used Blazor to build a recursive treeview: https://www.syntaxsuccess.com/viewarticle/experimenting-with-blazor

Thanks
Monday, March 25, 2019 8:12:18 AM UTC
@Mason @Scott

I've requoted what Chris said and added asterisks around the bit he is concerned about:

"This doesn't require Web Assembly on the client, the .NET code runs in the .NET Core CLR (Common Language Runtime) and has full compatibility - *****you can do anything you'd like as you are not longer limited by the browser's sandbox****"

Depending on what Scott means by this then this is VERY bad. The server being able to do anything it wants on your machine because the browser sandbox no longer matters would be a gaping security hole. I'm presuming though that Scott does not mean what he wrote in terms of the obvious literal mean the words have.
Peter
Monday, March 25, 2019 8:12:18 AM UTC
@Mason @Scott

I've requoted what Chris said and added asterisks around the bit he is concerned about:

"This doesn't require Web Assembly on the client, the .NET code runs in the .NET Core CLR (Common Language Runtime) and has full compatibility - *****you can do anything you'd like as you are not longer limited by the browser's sandbox****"

Depending on what Scott means by this then this is VERY bad. The server being able to do anything it wants on your machine because the browser sandbox no longer matters would be a gaping security hole. I'm presuming though that Scott does not mean what he wrote in terms of the obvious literal mean the words have.
Peter
Monday, March 25, 2019 8:13:11 AM UTC
@Scott

What I'd like to ask is - can Blazor be used on .NET full fat or is this another .NET Core only feature?
Peter
Monday, March 25, 2019 12:19:20 PM UTC
I like the concept of Blazor but isn't it just another "one language to rule them all, no need to learn Javascript" thing like all the ones before it? Wouldn't it be better to actually learn Javascript and use it properly than try to ignore it?
Wayne M
Monday, March 25, 2019 1:14:04 PM UTC
JavaScript will still be here when this stuff is long forgotten about.
Ramderjeet
Monday, March 25, 2019 2:59:51 PM UTC
Great article, Scott. One type - "You write C# in case of JavaScript" should be "You write C# instead of JavaScript"
Rick Hodder
Monday, March 25, 2019 4:52:17 PM UTC
This is exhausting. I am sick of javascript. I have high hopes for blazor but feel it's just the same old problems now in a new language built on primitive html that was never designed to do the things people are trying to do. Yes, I am sick of the web too. We don't do much html, the javascript handles that. We have a very large internal enterprise app and it's taking it's toll trying to 'fake' out a data intensive winform like UI in a browser with html and dom manipulations. It's so easy for the dom to get corrupted or the javascript errors and the app falls apart. Yeah, they are bugs we have to fix, but this stuff doesn't happen in a true native desktop gui like WinForms. If I throw an exception trying to dynamically add a C# WinForm button or insert a new grid row that doesn't cause my entire GUI to fall apart and rerender all wrong. We're actually debating going back and starting to build a new client in WinForms even though it seems Microsft is giving up on that as well, open sourcing it. I can't help but feel the entire industry has been on such a bad path for a long time and decades from now, people are going to look back on us and say what fools we were for all this mess. I wish I could see some kind of progress on trying to help us build winform apps in a browser, but without a dom and without 'fake layout controls' made up of complicated tables, divs, css, etc. Grids are a mess, editable grids are worse, trying to control focus is so hard, modal dialogs are not reliable, etc. There is more to life than everybody trying to build another online store site, another blog or a facebook knock off. I feel absolutely no attention is being given to business customers trying to build data intensive internal applications. I keep praying that someday I am going to see the evolution of WinForm for the web, works in every browsers, no html, no javascript, no dom, and development will be just like WinForms today and I can layout using the WinFormDesigner, etc. Events will be reliable, panels, dialogs, grids, etc. Instead, just more talk of constantly building upon the same old stuff (html) that wasn't designed for this stuff.
Pat
Monday, March 25, 2019 11:17:28 PM UTC
I would love to find the balance between SSR Razor Components and Blazor Components. How could we mix the two, based on features? Some PWA features need to work offline, so Blazor is better choice there (eg. service worker management).

If the separate server/client states were automatically distributed (eg. Ignite.NET), on-demand functionality could move to/from client as needed, providing interesting opportunities while minimizing client resources.

Also, has there been any interop testing with Blazor Components against other WASM languages (Python, Elixir, Go, etc.)?
Michael Paine
Monday, March 25, 2019 11:37:25 PM UTC
It was at first confusing to read the term "Razor Components" as being something other than View Components in Razor pages (link). The names are too similar to me. It has also been up to this point easy to know there is a difference between Blazor and Razor pages. I'd feel on more stable ground if the term for "Razor Components" could be flipped to "Blazor Components". But powers that be have determined it otherwise it would seem.

I have View Components working in my site and I do like the newer organization in Razor Pages. After a fairly quick learning curve I feel really productive using those. All the talk about Blazor makes me wonder if Razor pages will be thrown by the wayside in terms of popularity.

It will be interesting to see how Blazor evolves.
Tuesday, March 26, 2019 5:06:27 AM UTC
Anything that results in less JS is good; C# is even better. I like this a lot - hope this catches on, and I really, really hope there are a lot of smart people thinking of the possible security implications as per what Chris mentioned previously. I have the exact same worry - ActiveX all over again? Surely it must be sandboxed...
El Dorko
Tuesday, March 26, 2019 2:36:39 PM UTC
We've integrated the Blazor component model into ASP.NET Core 3.0 and renamed it to Razor Components. Blazor 0.8.0 is now built on Razor Components and enables you to host Razor Components in the browser on WebAssembly.
Tuesday, March 26, 2019 4:45:34 PM UTC
Hi Scott, In your article you mentioned .cshtml vs .razor (which read like something newer):
"You may have written Razor in the past in .cshtml files, or more recently in .razor files"

I haven't found any explanation for the .razor extension.

Can you clarify on that?

Thanks!

Yaniv
Wednesday, March 27, 2019 2:52:40 AM UTC
Hi Mangazuki,

Yes, I think you understand my point that Microsoft has chosen to obscure the name of a technology, again, and is creating yet another round of confusing marketing around what should be a technology that can be clearly judged by its own merits. Call all the things that work in a Blazor architecture simply, "Blazor". Don't conflate the use of the @ symbol as being "razor" as that is a relic of Asp.Net development paradigms. This is new and different, worthy of its own name, and should be clear instead of muddled. Or is this really razor syntax (the @ symbol) that can be used in Blazor, a new technology? And Razor syntax is not Blazor but Blazor can interpret Razor syntax? Looking for a consistent naming convention, that's all.
Wednesday, March 27, 2019 4:57:39 AM UTC
Hi Scott, Thanks for the well informed post. I've seen a few Blazor articles and videos and this one is clear and concise. I'd would like to know your thoughts on a comparable tech, Ooui (https://github.com/praeclarum/Ooui), which also converts C# to wasm but goes a step further and uses Xamarin.Forms to create web elements.
Jeff
Wednesday, March 27, 2019 6:04:27 AM UTC
Simple request: May you stop your blog from adding
dir="rtl"
to page bodies for people who have Arabic as their preferred browser language?
I always used to write Stylish/Greasemonkey scripts for your blog to remove that attribute, but it should be removed from the source as all the content is already in English.
Sunday, March 31, 2019 7:59:25 AM UTC
Excellent items from you, man. I have bear in mind your stuff prior to and you are just extremely excellent
Monday, April 01, 2019 7:52:42 AM UTC
Microsoft is changing the naming (back): Rename Razor Components back to server-side Blazor
Monday, April 01, 2019 1:45:58 PM UTC
Best news I have heard today! Good to see others had similar concerns about the naming for this and Microsoft made some adjustments. Blazor is moving so fast! The name is apt. https://github.com/aspnet/AspNetCore/issues/8931
Monday, April 01, 2019 6:39:46 PM UTC
Hi Scott, Thanks for this post.

I know it's not possible but i wish blazor could just be a middware that you add it the request pipeline then Bibbidi Bobbidi Boo. For all I know middware always performs magic.

By the way. Pls did you mean Razor Components can be added to an exiting asp core application to perform the work of blazor.
Prince Owusu
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.