September 2018
Volume 33 Number 9
[Editor's Note]
.NET in the Browser
By Michael Desmond | September 2018
.jpg "Michael Desmond")
In February, Microsoft Senior Engineer Steve Sanderson announced that the ASP.NET team had taken formal ownership of Blazor—an experimental Web UI framework he created that’s based on C#, Razor, and HTML and runs in the browser. The announcement set off a bit of a firestorm. After all, the project aims to do what earlier efforts like Silverlight could not: Enable developers to write .NET-based Web apps for the browser without a plug-in.
The secret behind Blazor is WebAssembly, a standard, binary instruction format that provides a portable target for compiling high-level languages like C++. WebAssembly is supported by all mainline browser families—desktop and mobile—released since mid-2017. Blazor leverages work from the Xamarin Mono project, enabling a .NET runtime for the Web. Code compiled to WebAssembly can run in any browser at native speeds.
Microsoft Principal Program Manager Daniel Roth has been elbow deep in Blazor going back to the February announcement, and helped vet two articles in this month’s issue focused on it: Jonathan Miller’s “C# in the Browser with Blazor” and Dino Esposito’s Cutting Edge column, “Never Mind JavaScript, Here’s Blazor.” I asked Roth about his thoughts on Blazor and the promise it holds for .NET developers.
“With WebAssembly, for the first time, we have the opportunity to enable full-stack Web development with .NET, where you can use the .NET languages, frameworks, and tools to fully utilize the browser in an open and standardized way,” Roth says. “We’re seeing interest in Blazor for writing a wide variety of applications, from line-of-business apps to health care apps to games.”
Since the February launch of the Blazor project, the ASP.NET team has been releasing updates every one to two months, with version 0.5.0 shipped in July. Roth says the most recent spin does some pretty cool stuff.
“Our latest Blazor release explored running Blazor in a separate process from the rendering process. For example, you might run Blazor in Web Worker, in an Electron app, or even server-side on .NET Core, and then handle all the UI updates and event handling over a cross-process channel.”
Roth offers the example of Blazor running on the server-side and using SignalR to connect with clients. The approach eliminates the need to download a full .NET runtime to the browser.
“The nice thing about this model is that it’s completely symmetric with running Blazor in the browser, but all the existing .NET libraries and tools just work, and you don’t have to pay the cost of downloading a full .NET runtime into the browser.”
There’s plenty of work ahead, says Roth. The WebAssembly-based .NET runtime needs improvement—smaller download sizes, better runtime performance and support for .NET Standard 2.0 are all priorities. The IL linker needs refinement to scrub more unused code from apps, and the team plans to explore support for Ahead-of-Time compilation of .NET code. And there’s more.
“Besides the runtime, we need to complete the Blazor component model to support scenarios like template-based components, forms and validation, and handling more event types. We’d also love to have a tooling story for Blazor apps that can run cross-platform in Visual Studio Code,” says Roth.
Blazor remains very much an experiment-in-progress, but one that could redefine Web application development. This much is certain: We’ll be keeping an eye on this promising effort in the months and years to come.
Michael Desmond is the Editor-in-Chief of MSDN Magazine.