This article is more than 1 year old
Blazor: Full stack C# and Microsoft's pitch for ASP.NET Web Form diehards
'Two to three times faster' in .NET 5.0 - but is running .NET in the browser a good idea?
Microsoft is pitching its Blazor framework, the newest addition to the ASP.NET Core platform, as a suitable upgrade for C# developers still wedded to Web Forms, the programming model dating back to the first release of the .NET Framework in 2002.
Web Forms were designed to make the transition to web applications easy for desktop developers. There is a visual designer, a toolbox with controls like buttons and listboxes, and developers can double-click a control and write C# code that runs on the server.
The stateless model of the web is disguised by a post-back system and a hidden ViewState variable that records the state of the controls. The apparent ease of use won wide adoption from Microsoft-platform developers, but the framework also has frustrations, being hard to integrate with unit tests, vulnerable to issues and bugs when the ViewState-driven abstraction does not work as expected, and out of step with modern JavaScript libraries.
Despite its age, Microsoft said last year that "almost half a million web developers use ASP.NET web forms every month."
That is in some ways curious, since it is over a decade since Microsoft released ASP.NET MVC (2009), a web framework intended to solve the issues with web forms. ASP.NET MVC – where the MVC stands for Model View Controller – has controller files which handle routing and some business logic, and a view engine which renders web pages.
The model aspect abstracts the database, often using Microsoft's Entity Framework object-relational mapping. ASP.NET MVC has a cleaner approach and is amenable to unit testing. The original view engine used web forms without the post-back system, but this was soon replaced by a new engine using a syntax called Razor to embed dynamic content into HTML and JavaScript.
Razor has endured, though ASP.NET MVC has given way to Razor Pages, similar but with a more logical design (and acknowledging that the “MVC” aspect was never pure). Although ASP.NET MVC or Razor Pages is now the mainstream choice, why have so many stuck with web forms? The answer perhaps is that it is easier to learn, and lets developers write all their code in C# or Visual Basic; if the goal is a solution to a business problem, it is often good enough. There are parallels with Microsoft’s desktop frameworks, where Windows Presentation Framework fixed many issues with the older Windows Forms (scaling, graphics acceleration, rich design) but its greater complexity meant that many developers refused to shift.
Microsoft is continuing to support web forms, but the technology is now frozen and has not been ported to ASP.NET Core. It is largely Windows-only, though cross-platform Mono has some support).
Enter Blazor
Enter Blazor, the newest web application framework to come out of Microsoft’s ASP.NET team. Blazor appeared on the scene in early 2018. Microsoft apparently believes this may be the thing that grabs some Windows Forms holdouts and has provided an ebook on how to migrate, though it also stated that “migrating a code base from ASP.NET Web Forms to Blazor is a time-consuming task.”
A Blazor application has the code in a standard .NET assembly but the user interface is standard HTML and CSS
Blazor is not very like web forms but has some things in common. One is that developers can write C# everywhere, both on the server and for the browser client. Microsoft calls this “full stack C#”.
“Blazor shares many commonalities with ASP.NET Web Forms, like having a reusable component model and a simple way to handle user events,” wrote the authors. The Blazor framework comes in several guises. The initial concept, and one of the options, is Blazor WebAssembly (Wasm). The .NET runtime is complied to Wasm, the application is compiled to a .NET DLL, and runs in the browser, supplemented by JavaScript interop.
Having a peek at Blazor WebAssembly is easy. Install the SDK – for example the hot new .NET 5.0, set for release next week – and type:
dotnet new blazorwasm -o BlazorHello
Then type:
dotnet watch run
to run the sample application. It is instructive to look at a release build. There is BlazorHello.dll, a assembly like any other.
Under net5.0\wwwroot\_framework you find all the gubbins: framework assemblies, the runtime called dotnet.wasm, and the JavaScript library blazor.webassembly.js that stitches it all together. This folder is alarmingly large: over 34MB in our case. It is not as bad as it seems since files exist both uncompressed and in .gz compressed form, and they will not all be requested. One that is essential is the runtime, dotnetwasm.gz, which is just over 1MB, or 2.7MB uncompressed.
The sample app notes “Loaded 8.67 MB resources. This application was built with linking (tree shaking) disabled. Published applications will be significantly smaller.”
The Blazor runtime files are alarmingly bulky but compression and eliminating unused code brings the size down for published applications
It is also notable that the HTML delivered to the browser is little more than a div element to contain the application. At runtime the JavaScript populates this with the controls that form the user interface. These are standard HTML controls though, not a black-box canvas element.
Blazor is designed for single-page applications and is reminiscent of Silverlight – Microsoft’s browser plugin in which ran .NET code in the browser - but with an HTML/CSS user interface.
There are two other Blazor application models. Blazor Server runs on the server and supports a thin browser client communicating with WebSockets (ASP.NET SignalR). The programming model is the same, but it is a thin client approach which means faster loading and no WebAssembly required; it can even be persuaded to run in IE11.
Then there is Mobile Blazor, recently updated to Preview 5, which uses the Blazor programming model but with either HTML UI or Xamarin forms (native UI) to run as a mobile application.
Although the mobile bindings are described as experimental it looks like Microsoft is serious about the project. The new preview adds support for SkiaSharp graphics, gesture recognisers, dual-screen support, DataPicker, TimePicker, simplified Grid layout and more.
The programming model feels like a cross between Razor Pages and web forms. It is easier than Razor Pages for getting started, but uses the same Razor syntax. State is held in the browser during a session; it is a single-page application so the round-trip issues in web forms do not exist, unless the user unwisely refreshes the page.
Persisting state across sessions is via standard web technology, such as interacting with a database on the server, but with built-in support for local browser storage to enable offline use. Building as a PWA (Progressive Web Application) is a built-in option. Developers can also use Microsoft’s identity system to get instant support for registration, log-in, authentication and so on; or they can use Azure Active Directory.
A big win for productivity is that code can be shared between the client and the server and works the same way. Developers can set up a project with shared classes. This makes it easier to work with the same business objects on client and server.
Developers should note that with the WebAsssembly model, all the client code ends up in the browser and potentially can be reverse engineered. This means care must be taken to avoid sending secrets or access to privileged APIs down to the browser. The same is true of single-page JavaScript applications, but .NET developers used to having their code run on the server may need to rethink some approaches to security.
Blazor in .NET 5.0 is substantially improved. The big deal is that "Blazor WebAssembly in .NET 5 is two to three times faster for most scenarios," according to the release notes. Other changes include component-specific CSS, ability to set UI focus in code, new InputFile component for file upload, Microsoft Identity v 2.0, and more.
Where does Blazor fit in Microsoft's complex array of developer products? It is not a breakthrough for web applications, since delivering applications as .NET assemblies has downsides and this will not be ideal for modern JavaScript frameworks like React. Interop between WebAssembly and JavaScript works, but is slow. Equally, developers already comfortable with ASP.NET MVC or Razor Pages are likely happy to continue running JavaScript on the client. There is a sweet spot though for C# developers with plenty of existing .NET code and experience who now have a route to a cross-platform web application framework that should be as good or better for quick business-oriented applications than web forms.®