With these three updates, you can create new or upgrade existing Blazor applications to the latest and greatest.
The following ASP.NET blog shows the steps necessary to upgrade your existing project, and also shows the changes that are getting close to the release naming conventions.
Notably the term Blazor is being phased out for the official branding of ASP.NET Components.
The Blazor Namespace is now Microsoft.AspNetCore.Components, rather than Microsoft.AspNetCore.Blazor
BlazorComponent is now called ComponentBase.
BlazorLayoutComponent is now just LayoutComponentBase
The simple JSON parser has been replaced by Newtonsoft’s parser, a welcome addition for those of us that need the advanced features of that parser. It was previously possible to use the Newtonsoft parser, but you needed to disable IL linking, which resulted in a much larger package size.
Visual Studio 2019 now has tooling by default.
.NET 3.0 support. Previously Blazor was limited to .NET core 2.1 (not even 2.2). With this upgrade, Blazor runs nicely in 3.0, with a performance boost.
Finally there is some client/browser side debugging. This should make for far better development experience.
You may or may not have heard of WebAssembly, or the Mono Framework, but Microsoft is blending them to wonderful platform goodness, for the future of the web. So, you may never need to understand either to take full advantage.
Keep in mind these are all experimental bits, at the moment. You can learn more at Blazor.net
WebAssembly (Wasm) is a part of all major modern browsers. It is a binary format for execution in a browser’s controlled sand-box. It is meant to be an intermediate format and not written directly, but it can be. In general you compile from a high level language to Wasm. It serves a similar purpose to JavaScript, but is not intended to be a replacement for JavaScript. In my opinion will take a large bite out of JavaScript’s stranglehold on client code; especially with Microsoft’s help.
The Mono framework was started in 2004. The .NET framework and compilers were Windows only. The Mono open-source project implemented the .NET APIs, based on the same ECMA-335 open standard, that was implemented in the official .NET. This allowed compiling and running .NET code on non-Windows systems, such as Linux and MacOS.
Blazor is an experimental Single-page application (SPA) framework that combines C#, WebAssembly, and Mono to allow C# code to be compiled and run directly in the browser. The Mono framework is provided as WebAssembly. For now, at least, the browser will use Mono to interpret the client .NET dll’s; but the speculation is that the compiler will eventually minify and cross-compile the .NET dll’s directly to WebAssembly.
Blazor has a deployment mode that is coded in mostly the same way, but runs server-side. The Blazor code runs on the server, and only the view differences are sent to the browser, via a SignalR connection. This mode gives the same coding benefits, but since the Blazor client code runs on the server, delays between the browser and server can be seen. It also requires more server compute power. This deployment mode is scheduled to be released in .NET Core 3.0.
For a Blazor coding experiment we will use the client side mode, with some WebApi to get configuration data. I made a simple dashboard with widgets that are loaded via server configuration. The project is based on the Hosted Blazor template.
Widgets can be any Blazor component, but I kept my widgets all cards to keep a consistent look.
There is a simple widget that just takes it content as parameters
There is a countdown widget, that can either countdown to a date, or count from one date to another with progress
There is a life countdown, to tell you how many more days you have to an age
And for fun there is a bouncing ball demo on a canvas
This is a simple demo, so the Blazor widgets are compiled directly into the client app, using pages. The index page will request an array of WidgetSettings from the server’s WebApi