First off, who am I.
My name is David Vanderheyden. A dad of 3 awesome kids, husband, and a .NET enthusiast at Noest. In my Everlong quest to keep updated with new technologies, I found myself convincing colleagues of why I think Blazor should be on everyone's radar. Ever since the experimental Blazor releases I have been playing with this technology. In this first blogpost on Blazor I want to quickly share the what, how, and why. And hopefully, like with my colleagues I can trigger the interest within you for Blazor and why it’s kind of a big thing.
The good and the bad of 2020
2020 has been a tough year for a lot of us, due to the Covid-19 virus and 2021 is looking to be as challenging and tough as 2020. But 2020 was a great year for technological improvements, one of them where the release of Blazor WebAssembly and release of .NET 5. Microsoft has been making a lot of changes to the .NET Framework in an attempt to shift towards unifying .NET 5 framework (Figure 1). This framework is meant to run anywhere and build applications, ranging from desktop applications to the web, cloud, gaming, mobile, IoT, or even AI applications in a uniform manner.
The evolution of .NET Core
In June 2016 Microsoft released the first major version of .NET Core (Figure 2), the first cross-platform successor to the .NET Framework, that was focused on high-performance web and microservices.
With the release of the second major version, APIs and components were added to facilitate migrations of web applications to .NET Core. This was also the first step Microsoft made in shifting towards a unifying platform.
With the release of .NET Core 3.0 in September 2019, Microsoft announced support for ARM64, improved performances, adding JSON APIs, Windows Forms, and WPF to the framework. Only 3 months later, Microsoft released .NET Core 3.1 with only two big additions, key improvements to Blazor and Windows Desktop.
Wait, improvements on Blazor?
Yes, Blazor has been around for a little over 3 years. It started as an experimental project led by Steve Sanderson (Knockout.js), with the goal of building a client web UI framework based on .NET and WebAssembly. Since then Microsoft has shipped nine experimental Blazor releases until April 2019, when an official preview was released. Blazor server was officially released shortly after with the release of .NET Core 3. For Blazor WebAssembly we had to wait until May 2020 where it was officially released at Microsoft Build. Later on, in November 2020 the release of .NET 5 came with additional Blazor improvements and more features and improvements are on the roadmap for .NET 6, coming later this year.
What is Blazor?
Blazor currently has 2 major host scenarios, Blazor Server and Blazor WebAssembly. Both follow the SPA framework rules, but both work in completely different way.
Blazor server (Figure 3) runs as the name implies, on the server, and not in the client's browser. Your browser loads an entirely new page at the start. After that, all the interactions are sent to the server using SignalR. The server pre-renders the HTML content that changes and sends that content again using SignalR to the client's browser so it can dynamically rewrite the page. Blazor server essentially makes your browser some sort of terminal. This way of working has advantages and disadvantages, which should be considered carefully when choosing Blazor Server.
- Search engine friendly
- No start-up time
- Works on older browsers
- Easier to debug
- API/SERVER code is private
- Bigger security sandbox
- Server-side rendering
- Uses in-memory session for each client
- Clients are bound to the server containing the session, so load-balancing doesn't work
- The round trip (the interaction on the page is being sent to the server, server pre-renders the HTML, sends the HTML back as a package to the client, the client browser processes and displays page with changes) can feel slow and inactive when the server and the client's browser are not close to each other or have a slow network connection between them.
- large input content results in large network transfer
- The application is unresponsive when the connection with the server is lost until Blazor re-establishes the connection to the server.
- No offline support
Blazor WebAssembly runs completely on the client's browser. Note that this is not like previous attempts from Microsoft with Silverlight to host an in-browser application that required browser plugins. It uses web standard WebAssembly. WebAssembly allows the compilation of code for the web browser. A Blazor WebAssembly is therefore completely run by using WebAssembly within the browser. When launching the web application for the first time, it will load the application. After loading, it will run the application inside your browser. There are also things to be considered carefully when choosing Blazor WebAssembly
- Runs completely on the client's browser which means the server load is significantly reduced.
- Native speed
- Works off-line (obviously, it won't be able to talk to the server to sync data until it re-establishes a connection)
- No server-side dependency
- Capable of being run as a Progressive Web App
- Shared code (Client/Server)
- .NET Code in the browser
- It downloads all required .NET assemblies, so start-up time is slower than server-side
- WebAssembly does not yet support multithreading
- Bound to the browser sandbox
- Missing live hot reload
- Only works on newer browsers, which mean it doesn't work with most thin clients
- Tooling still needs to mature
What the future holds for Blazor
Some things that the roadmap contains to date that I find worth noting are:
- Hot reload for Blazor
- WebAssemmbly AoT (ahead-of-time) Compilation
- Improvements for Blazor Server
- Pause and resume Blazor applications
- Dynamic component rendering
- Update for Blazor head components
- Improve SVG support
- Drag & drop
The one that jumps out by far is Blazor Desktop Applications. Yes, you read this wright. In .NET 6 they want to extend Blazor’s target scenarios to include native desktop applications via web-based rendering. It mixes the Blazor WebAssembly application with concepts from Electron. This results in a hybrid environment that makes it possible for Blazor to be run inside a native application container and is possible to link with system-level services.
Additionally there has been work for yet another Blazor target scenario, namely Mobile Blazor Bindings Hybrid Apps. This is an experimental project that has been around for some time and to date is not yet committed. This target scenario makes it possible to build mobile applications with the ease of Blazor.
Essentially, what do these different Blazor target scenarios mean? It means that all the components can be shared via a Razor Class library and run on multiple scenarios. Imagine a web app, desktop native app and mobile app all sharing the same logic code and components. Simply said you write it once and host it anywhere.
For tooling it is a matter of time, to date visual studio preview already contains new features for working with Blazor projects. That solve a lot of issues you could come across. Hot reloading is something that I miss at the moment, but this is committed on the .NET 6 roadmap.
You can see on an image released in September 2019 that Microsoft is committed towards Blazor and to date follows this intent.
I’m over-excited about the status of Blazor today and what the near future will bring.
Today it already has so many benefits, we can’t look beside it. Microsoft suggests Blazor server for replacing legacy Webforms applications and I must say ‘Blazor server is Webforms done right”. But this proves the commitment from Microsoft in Blazor.
Most of all, the reusability of code and components benefits the development speed. Writing your code once and being able to distribute your application as a PWA, web App, WebAssembly App, soon Blazor Desktop application and hopefully Mobile Blazor App is simply put: Awesome. But also share models, validation and logic between your client and server is a huge benefit.
With Blazor as the technology of choice, back-end C# developers automatically have knowledge of front-end development with Blazor. Making it easier for back-end developers to shift between fixing bugs on the front-end or skill-up on building front-end applications.
Thanks for reading and stay safe.