News

Server-Side Blazor to Ship in .NET Core 3.0

Blazor is heading for the big time, to be packaged with the next major release of .NET Core, ready for production use. Specifically, some components of Microsoft's experimental Blazor project for running .NET code in the browser will be included in .NET Core 3.0, Microsoft said yesterday.

Even more specifically, only the server-side components of Blazor will be included in the ASP.NET part of .NET Core 3.0, Microsoft's open source, cross-platform, modular and modernized implementation of the .NET Standard.

The Blazor dev team is focused on running .NET code -- such as C# -- client side in the browser. But apparently the client-side efforts aren't quite ready for .NET Core prime time, as there are more moving parts and dependencies associated with the client-side effort, so progress isn't solely determined by the Blazor dev team. For example, to run Blazor in the browser, code must be compiled to WebAssembly, another brand-new work in progress that's basically bytecode for the Web.

Blazor dev leader Daniel Roth yesterday noted in a blog post that while server-side components are headed for .NET Core, the client-side efforts will continue as an experimental project "while we work through the issues of running .NET on WebAssembly."

Roth in a video presentation earlier this month noted there was still a lot of work involved "to take Blazor to not be an experimental project, lots of runtime work, so it's not ready for production quite yet."

Independent Blazor expert Chris Sainty provided more information in a post earlier this month:

The simple fact is that the client-side model relies not only on WebAssembly but also the efforts of the Mono team and their WASM .NET runtime. While progress is being made extremely quickly it's not quite there yet. AOT is not an option, there is extremely limited debugging, performance needs to be improved, download sizes are too big, etc.

The server-side model gives Microsoft a chance to get Blazor out there to people almost immediately. And as it runs on good old .NET Core it's also got a solid base. It's also important to remember that due to the Blazor architecture, with its separation of app execution from rendering, any developments made will benefit both models. So client-side is not going to get left behind.

The Blazor component model to be included in ASP.NET Core and shipped with .NET Core 3.0 was given the new name "Razor Components" to differentiate it from the ability to run .NET in the browser, Roth said.

"We are now working towards shipping Razor Components and the editing in .NET Core 3.0," Roth said. "This includes integrating Razor Components into ASP.NET Core so that it can be used from MVC. We expect to have a preview of this support early next year after the ASP.NET Core 2.2 release has wrapped up.

"Our primary goal remains to ship support for running Blazor client-side in the browser. Work on running Blazor client-side on WebAssembly will continue in parallel with the Razor Components work, although it will remain experimental for a while longer while we work through the issues of running .NET on WebAssembly. We will however keep the component model the same regardless of whether you are running on the server or the client. You can switch your Blazor app to run on the client or the server by changing a single line of code."

Blazor 0.6.0
The news about Razor Components was included in a blog post announcing the latest update to the project, Blazor 0.6.0.

One main new feature of the update is the addition of templated components. "Templated components are components that accept one or more UI templates as parameters, which can then be used as part of the component's rendering logic," Roth explained. "Templated components allow you to author higher-level components that are more reusable than what was possible before. For example, a list view component could allow the user to specify a template for rending items in the list, or a grid component could allow the user to specify templates for the grid header and for each row."

Another new feature is refactored server-side Blazor startup code to support the Azure SignalR Service. "In the previous Blazor release we added support for running Blazor on the server where UI interactions and DOM updates are handled over a SignalR connection," Roth said. "In this release we refactored the server-side Blazor support to enable using server-side Blazor with the Azure SignalR Service. The Azure SignalR Service handles connection scale out for SignalR based apps, scaling up to handle thousands of persistent connections so that you don't have to."

In his video presentation earlier this month, Roth said Blazor updates will continue to ship on a monthly basis, and the team hoped to have a preview of Razor Components ready early next year.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube