The .NET Stacks #33: 🚀 A blazing conversation with Steve Sanderson

It's a jam-packed issue this week, as we talk about Blazor with Steve Sanderson.

Dave Brock
Dave Brock

Happy Monday, all. What did you get NuGet for its 10th birthday?

This week:

  • Microsoft blogs about more .NET 5 improvements
  • A study on migrating a hectic service to .NET Core
  • Meet Jab, a new compile-time DI library
  • Dev Discussions: Steve Sanderson
  • Last week in the .NET world

Microsoft blogs about more .NET 5 improvements

This week, Microsoft pushed a few more blog posts to promote .NET 5 improvements: Sourabh Shirhatti wrote about diagnostic improvements, and Máňa Píchová writes about .NET networking improvements.

Diagnostic improvements

With .NET 5, the diagnostic suite of tools does not require installing them as .NET global tools—they can now be installed without the .NET SDK. There’s now a single-file distribution mechanism that only requires a runtime of .NET Core 3.1 or higher. You can check out the GitHub repo to geek out on all the available diagnostics tools. In other news, you can now perform startup tracing from EventPipe as the tooling can now suspend the runtime during startup until a tool is connected. Check out the blog post for the full treatment.

Networking improvements

In terms of .NET 5 networking improvements, the team added the ability to use cancellation timeouts from HttpClient without the need for a custom CancellationToken. While the client still throws a TaskCanceledException, the inner exception is a TimeoutException when timeouts occur. .NET 5 also supports multiple connections with HTTP/2, a configurable ping mechanism, experimental support for HTTP/3, and various telemetry improvements. Check out the networking blog post for details. It’s a nice complement to Stephen Toub’s opus about .NET 5 performance improvements.


A study on migrating a hectic service to .NET Core

This week, Avanindra Paruchuri wrote about migrating the Azure Active Directory gateway—and its 115 billion daily requests—over to .NET Core. While there’s nothing preventing you hosting .NET Framework apps in the cloud, the bloat of the framework often leads to expensive cloud spend.

The gateway’s scale of execution results in significant consumption of compute resources, which in turn costs money. Finding ways to reduce the cost of executing the service has been a key goal for the team behind it. The buzz around .NET Core’s focus on performance caught our attention, especially since TechEmpower listed ASP.NET Core as one of the fastest web frameworks on the planet.
In Azure AD gateway’s case, we were able to cut our CPU costs by 50%. As a result of the gains in throughput, we were able to reduce our fleet size from ~40k cores to ~20k cores (50% reduction) … Our CPU usage was reduced by half on .NET Core 3.1 compared to .NET Framework 4.6.2 (effectively doubling our throughput).

It’s a nice piece on how they were able to gradually move over and gotchas they learned along the way.


Meet Jab, a new compile-time DI library

This week, Pavel Krymets introduced Jab, a library used for compile-time dependency injection. Pavel works with the Azure SDKs and used to work on the ASP.NET Core team. Remember a few weeks ago, when we said that innovation in C# source generators will be coming in 2021? Here we go.

From the GitHub readme, it promises fast startup (200x more than Microsoft.Extensions.DependencyInjection), fast resolution (a 7x improvement), no runtime dependencies, with all code generating during project compilation. Will it run on ASP.NET Core? Not likely, since ASP.NET Core is heavily dependent on the runtime thanks to type accessibility and dependency discovery, but Pavel wonders if there’s a middle ground.


Dev Discussions: Steve Sanderson

It seems like forever ago when, at NDC Oslo in 2017, Steve Sanderson showed off a new web UI framework with the caveat: “an experiment, something for you to be amused by.” By extending Dot Net Anywhere (DNA), Chris Bacon’s portable .NET runtime, on WebAssembly, he was able to load and run C# in the browser. In the browser!

Of course, this amusing experiment has grown into Blazor, a robust system for writing web UIs in C#. I was happy to talk to Steve Sanderson about his passions for the front-end web, how far Blazor has come, and what’s coming to Blazor in .NET 6.

Steve Sanderson profile photo

Years ago, you probably envisioned what Blazor could be. Has it met its potential, or are there other areas to focus on?

We’re not there yet. If you go on YouTube and find the first demo I ever did of Blazor at NDC Oslo in 2017, you’ll see my original prototype had near-instant live reloading while coding, and the download size was really tiny. I still aspire to get the real version of Blazor to have those characteristics. Of course, the prototype had the advantage of only needing to do a tiny number of things—creating a production-capable version is 100x more work, which is why it hasn’t yet got there, but has of course exceeded the prototype vastly in more important ways.

Good news though is that in .NET 6 we expect to ship an even better version of live-updating-while-coding than I had in that first prototype, so it’s getting there!

When looking at AOT, you’ll see increased performance but a larger download size. Do you see any other tradeoffs developers will need to consider?

The mixed-mode flavour of AOT, in which some of your code is interpreted and some is AOT, allows for a customizable tradeoff between size and speed, but also includes some subtleties like extra overhead when calling from AOT to interpreted code and vice-versa.

Also, when you enable AOT, your app’s publish time may go up substantially (maybe by 5-10 minutes, depending on code size) because the whole Emscripten toolchain just takes that long. This wouldn’t affect your daily development flow on your own machine, but likely means your CI builds could take longer.

It’s still quite impressive to see the entire .NET runtime run in the browser for Blazor Web Assembly. That comes with an upfront cost, as we know. I know that the Blazor team has done a ton of work to help lighten the footprint and speed up performance. With the exception of AOT, do you envision more work on this? Do you see a point where it’ll be as lightweight as other leading front-end frameworks, or will folks need to understand it’s a cost that comes with a full framework in the browser?

The size of the .NET runtime isn’t ever going to reduce to near-zero, so JS-based microframeworks (whose size could be just a few KB) are always going to be smaller. We’re not trying to win outright based on size alone—that would be madness. Blazor WebAssembly is aimed to be maximally productive for developers while being small enough to download that, in very realistic business app scenarios, the download size shouldn’t be any reason for concern.

That said, it’s conceivable that new web platform features like Signed HTTP Exchanges could let us smartly pre-load the .NET WebAssembly runtime in a browser in the background (directly from some Microsoft CDN) while you’re visiting a Blazor WebAssembly site, so that it’s instantly available at zero download size when you go to other Blazor WebAssembly sites. Signed HTTP Exchanges allow for a modern equivalent to the older idea of a cross-site CDN cache. We don’t have a definite plan about that yet as not all browsers have added support for it.

Check out the entire interview at my site.


🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

🌎 Web development

🥅 The .NET platform

⛅ The cloud

📔 Languages

🔧 Tools

📱 Xamarin

👍 Design, testing, and best practices

🎤 Podcasts

🎥 Videos

.NET Stacks