The good and the bad of 2020
2020 has been a tough year for a lot of us so far, due to the Covid-19 virus. But it's shaping up to be a great year for technological improvements. And the year is not over yet, in November the expected official release of .NET 5 is something to follow up on. 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.
Figure 1 .NET 5 - a Unified Platform (source)
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.
Figure 2. Source Code Flow Concept from .NET, Mono and Shared Source Initiative to .NET 5 (source)
Wait, improvements on Blazor?
Yes, Blazor has been around for a little over two and a half 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 this year where it was officially released at Microsoft Build 2020.
What is Blazor?
Blazor currently has 2 ways of hosting, Blazor Server and Blazor WebAssembly. Both follow the SPA framework rules, but both work in completely different ways.
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 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
- Same code on the client as on the server
- 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 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.
Figure 3 Blazor Server (source)
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.
- Works off-line (obviously, it won't be able to talk to the server to sync data until it re-establishes a connection)
- Will not run directly from the local file system
- Capable of being run as a Progressive Web App
- Same code on the client as on the server
- It downloads all required .NET assemblies, so start-up time is slower than server-side
- Blazor WebAssembly does not yet support multithreading
- Only works on newer browsers, which mean it doesn't work with most thin clients
Figure 4 Blazor WebAssembly Source
What the future holds for Blazor
What the exact roadmap contains to date is unclear, since this is the last roadmap shown and dates from September last year.
There are a few Hybrid experiments ongoing that are worth following.
One of those is Blazor+Electron. Using Electron makes it possible to build desktop applications with the ease of HTML, but run them on any OS. Electron works by running Chromium, for the frontend code, and Node.js for the back-end code with WebAssembly. But this comes with a cost, it adds overhead to the system. A simple application easily becomes +50MB in size, and when launched it eats up +100MB memory.
Another experiment by Microsoft (Steve Sanderson) is named WebWindow. Same as Electron, WebWindow makes it possible to build desktop applications that run on any OS. But unlike Electron it doesn’t bundle Node.js or Chromium, making it more lightweight. WebWindow is just a prototype, so by far not production-ready. But this would be a game-changer for desktop application development.
Yet another experiment is mobile Blazor bindings, this should enable native mobile application development with Blazor. Thus making it possible to build mobile applications with the ease of HTML using Razor syntax.
June 2020 gRPC-Web for .NET officially released and makes it possible to connect a Blazor app with one or many gRPC services.
Huge improvements expected later this year on Blazor are component model improvements, hot reloading, and CSS isolation. WebAssembly-specific improvements expected later this year are multithreaded runtime and lazy loading.
Figure 5 (Source)
I’m over-excited about the status of Blazor today and things to come. Today it already has so many benefits, we can’t look beside it. A lot of developers who worked with Blazor say: “Blazor server is Webforms done right”. On top of that being able to make a complete client-side SPA with Blazor WebAssembly opens so many new opportunities. But most of all, the reusability of code and components benefits the development speed in the long run. Also making it possible to have everything inside the same stack and not distributed in multiple languages and/or frameworks, is a blessing for developers.
Thanks for reading and stay safe.