News
.NET 8 Preview 4 Boosts Native AOT, Blazor 'Streaming Rendering'
Microsoft's fourth preview of .NET 8 continues to boost native native Ahead-of-Time (AOT) compilation, while Blazor gets streaming component rendering.
The latter pertains to the new server-side rendering (SSR) functionality for Blazor in .NET 8, offered up months ago by Blazor creator Steve Sanderson, who called his new approach "Blazor United," a name that seems to have not stuck with the higher-ups at Microsoft.
In a February video, Sanderson said: "We've started some experiments to combine the advantages of Razor Pages, Blazor Server and Blazor WebAssembly all into one thing, so this would be a way for Blazor components to be a single architecture for all your web UI scenarios -- that's for plain HTML rendering and for full interactivity either server-side or on WebAssembly -- and that's all in one project with the ability to easily switch between different rendering modes and even mix them in the same page."
The project was added to the planning for .NET 8, set to debut in November, and appeared in April's Preview 3 as "server-side rendering with Blazor components." At the time, Microsoft's Daniel Roth, principal program manager for ASP.NET, said: "This preview adds initial support for server-side rendering with Blazor components. This is the beginnings of the Blazor unification effort to enable using Blazor components for all your web UI needs, client-side and server-side. This is an early preview of the functionality, so it's still somewhat limited, but our goal is to enable using reusable Blazor components no matter how you choose to architect your app."
Now, in this week's release of Preview 4, Roth explained streaming rendering with Blazor components.
"You can now stream content updates on the response stream when using server-side rendering (SSR) with Blazor in .NET 8," he said. "Streaming rendering can improve the user experience for server-side rendered pages that need to perform long-running async tasks in order to render fully."
[Click on image for larger, animated GIF view.] Blazor Streaming Component Rendering in Animated Action (source: Microsoft).
"For example, to render a page you might need to make a long running database query or an API call," Roth continued. "Normally all async tasks executed as part of rendering a page must complete before the rendered response can be sent, which can delay loading the page. Streaming rendering initially renders the entire page with placeholder content while async operations execute. Once the async operations completes, the updated content is sent to the client on the same response connection and then patched by Blazor into the DOM. The benefit of this approach is that the main layout of the app renders as quickly as possible and the page is updated as soon as the content is ready."
Another Blazor SSR enhancement adds the ability to use Blazor components to handle form posts.
In response to a comment from a reader questioning whether the streaming rendering demo really demonstrated how it works, Roth provided more information: "The big difference with streaming rendering from what you can do today with Blazor is that streaming rendering is based on server-side rendering without the need for a stateful WebSocket connection. The UI experience is handled over a single request/response interaction with the server."
Roth also announced other new features and tweaks for Blazor in particular and many others for ASP.NET Core in general, spanning: API authoring; authentication and authorization; ASP.NET Core metrics; and native AOT.
Native AOT
The latter native AOT functionality has been boosted across the board in .NET 8 previews, as it's a focal point of the dev team after a survey revealed years ago that the lack of much-requested native AOT was holding back developers from using .NET more.
[Click on image for larger view.] "Does the lack of officially supported native AOT option prevent you from using .NET more?" (source: Microsoft).
Native AOT improvements in .NET 8 start out with an updated console template, now supporting AOT by default.
"It's now possible to invoke dotnet new console --aot to create a project that is configured for AOT compilation," said Microsoft's Jon Douglas in a May 16 announcement." He said the project configuration added by --aot has three effects:
- Publishing the project with e.g.
dotnet publish or with Visual Studio will generate a native self-contained executable with native AOT.
- It will enable Roslyn-based compatibility analyzers for trimming, AOT, and single file that will mark potentially problematic parts of your project (if there are any) in your editor of choice.
- It will enable debug-time emulation of AOT so that when debugging your project without AOT compilation, you get a similar experience to AOT. This makes sure that e.g. use of Reflection.Emit in a NuGet package that wasn't annotated for AOT (and was therefore missed by the compatibility analyzer) won't surprise you when you try to publish the project with AOT for the first time.
Other native AOT changes announced by Douglas include improving fundamentals such as runtime throughput, memory use and size on disk with Native AOT. Also, developers can now specify an optimization preference, weighted toward speed or size, letting them tweak their preference toward one or the other. While the default setting seeks to strike a balance between the two, devs can now indicate how much they want to trade off between size and speed. "In Preview 4, we observed that optimizing for speed produces 2-3 percent improvements in throughput for real world workloads," Douglas said.
Over on the web-dev side of things, Roth announced a raft of native AOT changes concerning:
- Logging and exception handling in compile-time generated minimal APIs
- ASP.NET Core top-level APIs annotated for trim warnings
- Reduced app size with configurable HTTPS support
- Worker Service template updates
- Additional default services configured in the slim builder
- API template JSON configuration changes
- Support for JSON serialization of compiler-generated IAsyncEnumerable unspeakable types
EF Core
EF Core 8 in Preview 4 was the subject of a separate announcement, which detailed multiple improvements to LINQ, OpenJson, queryable inline collections and much more.
Microsoft's Shay Rojansky explained what's supported and what's not.
"The fourth preview brings primitive collection support for SQL Server and SQLite; the PostgreSQL provider will also be updated to support them," Rojansky said. "However, as indicated above, this is the first wave of work on primitive collections -- expect further improvements in coming versions." Specifically, he said:
- Primitive collections inside owned JSON entities aren't supported yet.
- Certain primitive data types aren't yet supported on certain providers; this is the case with spatial types, for example.
- We may optimize the SQL around OpenJSON to make querying more efficient.
More Info
More general information about what's coming for .NET 8 can be found in:
About the Author
David Ramel is an editor and writer at Converge 360.