Blazor is a new web framework from Microsoft designed to compete with industry-leading platforms like React. Except, instead of using JavaScript, it runs on the .NET runtime, and allows developers to make interactive web apps with C# and HTML.
What Is ASP.NET Even?
If you’re coming from the world of JavaScript frameworks, you might be confused about Blazor’s relationship with ASP.NET. They’re both “web frameworks,” but Blazor is just one part of the ASP.NET ecosystem.
While the ASP.NET platform is nearly 20 years old at this point, it isn’t a dinosaur framework—it’s been consistently improving alongside C# and .NET as a whole, as Microsoft uses it internally. It’s completely cross-platform and as performant as ever.
In the beginning, there was just ASP.NET, which can be used to make all sorts of web applications. There was ASP.NET MVC (Model-View-Controller), which creates data-driven web pages, and ASP.NET WebAPI, which specializes in backend APIs. These were recently merged into a unified package with the modernized ASP.NET Core.
Five years ago, Razor Pages (which is a separate thing from Blazor and confusingly named) was released to simplify the expressive syntax of MVC, which requires a lot of boilerplate and, as such, doesn’t play well with the component-focused design of modern applications. MVC requires you to make a view and model for each page in separate files:
Meanwhile, with Razor, you can make more streamlined pages or components with integrated code on the page itself. This works better when the pages are simpler, but both are available as options for you to use.
All of these features are part of the “ASP.NET” ecosystem. The great part about it is the packages and support. Much like NPM for JavaScript, C# also has a healthy package environment with the NuGet package manager.
So What Is Blazor?
Blazor doesn’t change anything about the syntax of these pages. You’ll still be using Razor pages and/or MVC. This actually isn’t even a bad thing, because there are already numerous UI and component libraries made for C#-backed Razor pages.
What Blazor adds is interactivity. Traditional MVC/Razor pages using ASP.NET have always been clunky and have struggled to keep up with real-time web applications like React. Real-time web apps are so fast that they’re starting to take over the desktop as well, with frameworks like Electron running apps in a Chromium container, with users none the wiser.
So, Blazor was created to meet this demand. It works a lot like React, where actions modify state and props and trigger updates to the app. The framework will handle updating the DOM for you based on which components need updating. This enables real-time applications where the page can be updated or even completely redrawn without having to actually refresh the browser.
The benefit of Blazor over an established framework like React is the language. It lets you build web apps with C#, and that alone makes it alluring to many developers. Whatever opinion you might have on the dynamic vs. static typing debate, there are definitely benefits to “desktop” languages like C#, and the web is seriously lacking in alternatives to JavaScript.
If you have a backend that requires high performance, C# will also run a lot faster than JavaScript. Even though JS is by no means slow and has improved a lot over the years, it will still end up less performant than C#, which actually runs pretty close to native C++ performance.
Blazor allows for better interoperability. Many apps also already use C# on the backend. For example, you might have an ASP.NET API that interacts with your React frontend. You’ll need separate models for the server and the client side as well as separate code for interacting with them. If they’re the same language, it allows you to easily share code and libraries between client and server. This is the entire reason why NodeJS exists on the server side—even though JavaScript is not the ideal desktop language, having apps built in one language cuts down on development time.
The Future of Blazor
There are actually a few different types of Blazor, as Microsoft has been making a big development push recently to modernize the ASP.NET ecosystem. Currently, there are two versions that have been released:
- Blazor Server, which works like React Server Side Rendering and does most of the processing on the server.
- Blazor WebAssembly, which uses the magic of WebAssembly to run actual .NET code in an actual client web browser.
Microsoft also plans to release three more versions of Blazor, which are still in development and available for preview:
- Blazor PWA, which is designed around publishing the site as an installable Progressive Web App (PWA).
- Blazor Desktop/Hybrid, which allows Blazor apps to be packaged into desktop apps and is basically like Electron but with better performance.
- Blazor Native, which replaces the web-based UI with a platform-native interface. It’s not clear how useful this even is besides interop with existing Blazor tools, and this version is still in the planning phases.
In their announcement for Blazor Desktop, Microsoft stated that “Blazor is an application programming model. It is very adaptable, and can be executed in multiple ways (depending on the need).”
Microsoft seems to think of Blazor as their next standard for making application frontends. Their work is well worth it, too, because as applications become more and more web-dependent, it’s harder to justify creating separate frontends for web and desktop. Blazor has a bright future, and web applications made today on Blazor Server and WebAssembly will have a lot of room to grow.
Blazor Server vs. Blazor WebAssembly
Blazor Server uses a SignalR connection to communicate between the client and server. This is just a fancy layer on top of a WebSocket connection, which can optionally fall back to other connections when needed. This keeps all of the processing on the server and leaves the client as a simple view with a basic way to manipulate the DOM.
Blazor WebAssembly is where it gets seriously cool. WebAssembly (WASM) isn’t really a language that you write in, but a compiler target. It actually works almost exactly like the Microsoft Intermediary Language (MSIL) that all C#, F#, and VB.NET compile to. Except that, rather than running with a .NET runtime, it runs using the WebAssembly runtime in the browser.
The cool part about WebAssembly is that it’s a relatively easy compiler target to hit. Much like how C# can compile down to MSIL, C# can also compile to WebAssembly. Well, technically, it’s MSIL compiling to WebAssembly (as that’s simpler), but the point is the same.
Any language can compile to WASM, even fully native desktop languages like C++. This isn’t theoretical—it actually works in practice. AutoDesk was able to port AutoCAD, a 30-year-old C++ codebase, over to a WebAssembly-based web app, in a few months with relative ease. Someone even ported Doom 3.
Blazor WebAssembly basically takes the entire server as well as the .NET runtime and runs it on top of WASM. Then, instead of talking to the server over SignalR, it directly talks to the DOM. This cuts out the server side processing, which can be ideal for some apps.
This makes it uniquely positioned to compete with frameworks like React, as it’s essentially the first true competitor to JavaScript for client web applications. While you have to add a few script tags to load the runtime and might have to dip your toes into JavaScript code for a few things, you should, for the most part, be able to make an entire production web app without writing a single line of JavaScript.
Whether you use Blazor Server or Blazor WebAssembly is up to you. They both have their advantages. Blazor Server runs all processing code in a trusted environment and doesn’t require you to have a public API. Blazor WASM is responsive and fast, and can even be deployed as a static site served with just NGINX.
How Does Blazor Work with JavaScript?
In either case, you actually have full JavaScript interoperability. Blazor can call JS functions from managed code:
private async Task ConvertArray()
{
text = new(await JS.InvokeAsync<string>("convertArray", quoteArray));
}
And vice versa:
DotNet.invokeMethodAsync('{ASSEMBLY NAME}', '{.NET METHOD ID}', {ARGUMENTS});
Although, keep in mind that this will, of course, use reflection, and certainly isn’t the most performant thing in the world.
You can technically use all NPM packages with Blazor, although setting that up and interacting with it from the .NET side might be a bit of a headache, so you should prefer a NuGet package most of the time.
Can You Use Blazor on Desktop (Electron)?
Surprisingly, the answer to this is yes. While Microsoft plans to release Blazor Desktop/Hybrid, which does the same thing, in the meantime, you can actually just use normal Electron. This is because Electron really doesn’t care about what web page it’s serving and can just serve a Blazor app.
You might think that it would use a Blazor WebAssembly app, but it’s actually easier to just add Electron to an existing ASP.NET Core server. WASM does have some overhead, so this method is faster. That’s what Electron.NET does, and it works surprisingly well. All you have to do is install it and add Electron as an ASP.NET service. You can also call Electron native functions from C#.
Microsoft has bigger plans for Blazor Desktop, though. They plan to completely get rid of the dependence on a browser and JavaScript and just run a native container with a web view that’s .NET all the way down.
“Blazor desktop will be structured similarly to the way Electron works. There will be a WebView control that renders content from an embedded Blazor web server, which can serve both Blazor and other web content (JavaScript, CSS, etc.).”
This web view would use Safari, WebKitGTK, or WebView2, depending on the OS. WebView2 uses Chromium under the hood, so it would function a lot like Electron, except for being more performant and using less memory.
Whatever the implementation ends up being, it’s exciting to see another platform competing with JavaScript and Electron for building cross-platform web and desktop apps. Blazor Desktop should be released in November of 2021 with .NET 6’s first preview.
