News

.NET 7 WebAssembly Plans: Mixed-Mode AOT, Multi-Threading, Web Crypto

• By David Ramel
• 02/18/2022

In creating .NET 7, Microsoft will continue to improve functionality for WebAssembly, the tech behind client-side Blazor, with plans to boost Ahead Of Time (AOT) compilation, multi-threading and cryptography support.

Blazor WebAssembly is the name of that client-side component of Blazor, which allows for web coding in C# instead of JavaScript. WebAssembly serves as an assembly language-like compilation target to run C# code in the browser.

With the first preview of .NET 7 shipping this week, Microsoft outlined plans for WebAssembly functionality in a post about updates to ASP.NET Core, the web-dev framework where Blazor lives. If measured by the number of work items in the ASP.NET Core Roadmap for .NET 7, Blazor is by far getting the lion's share of developer attention.

According to this week's post, among the areas to see broad improvements in the .NET 7 dev cycle are: "New .NET WebAssembly capabilities: mixed-mode AOT, multithreading, web crypto."

Mixed-Mode AOT
The functionality surrounding that first item has been present for a while now, as AOT came to Blazor last May in a .NET 6 preview. At the time, Daniel Roth, principal program manager for ASP.NET, said: "Blazor WebAssembly now supports Ahead-Of-Time (AOT) compilation, where you can compile your .NET code directly to WebAssembly for a significant runtime performance improvement. Blazor WebAssembly apps today run using a .NET IL interpreter implemented in WebAssembly. Because the .NET code is interpreted, typically this means that .NET code running on WebAssembly runs much slower than it would on a normal .NET runtime. .NET WebAssembly AOT compilation addresses this performance issue by compiling your .NET code directly to WebAssembly."

Mixed-mode AOT refers to taking parts of the IL (Intermediate Language) code and compiling it to WebAssembly to be run in the browser. It falls short of "full" AOT, which can't be done in Blazor for technical reasons.

The "mixed-mode AOT" item in the announcement post penned by Roth was called into question in a reader comment:

Blazor doesn't have full AOT yet as reported in Blazor AOT .Net6 Preview 7 -- Still downloading Dlls #35302, yet this issue is closed and full AOT is marked as complete (Developers can AOT compile .NET apps into WebAssembly format), and now Microsoft is moving to Mixed AOT as if full AOT were already there. Full AOT is pretty essential for deploying apps on browsers with good startup performance and file size. I think better for devs who want to deploy apps on browsers to give up on Blazor and focus on the work done in runtimelab on NativeAOT WASM which seems a lot closer to having a usable wasm compilation toolchain.

Here is Roth's reply:

You're correct that we still rely on .NET IL interpretation in some cases when using ahead-of-time (AOT) compilation for WebAssembly. This is because certain .NET runtime features still require it. So "full" AOT in this case really means we AOT compile as much as we can. There is ongoing work to further improve WebAssembly AOT to reduce the need for using the interpreter, but it's unlikely we'll be able to remove it completely given the limitations WebAssembly currently imposes.

Please also note that if download size is an issue, AOT compilation in general isn't going to help even if we could fully remove the need for interpretation. AOT compiled code is generally larger than the original .NET IL instructions, about 2x larger. As we further reduce the need for interpretation, we can somewhat reduce the size of the app by further trimming the .NET assemblies, but the app will still be larger than if it wasn't using AOT at all. Where WebAssembly AOT compilation helps is with improving runtime performance for CPU intensive work.

We're also aware of the NativeAOT LLVM backend work and excited to see how it plays out!

Lack of native AOT has been a .NET Core issue for a while, with Microsoft in 2020 publishing results of a survey indicating that the lack of AOT was keeping developers from using .NET Core more.

Multi-Threading
The multi-threading issue, meanwhile, has been batted around since December 2019 when an issue was opened calling for "Multithreading which is available already in WEBASM to be exposed to Blazor Client side." More than two years -- and 69 comments -- later, Roth yesterday posted the last comment on the thread: "Support for multithreading in Blazor WebAssembly is planned for .NET 7. Plans can still change, so we'll see how it goes."

Web Crypto
This stems from a July 2020 issue: "Developers targeting browser-wasm can use Web Crypto APIs." It says the dev team would like to use platform-native crypto functions and avoid shipping OpenSSL for Browser.

It also points to SubtleCrypto documentation, which says: "The SubtleCrypto interface of the Web Crypto API provides a number of low-level cryptographic functions. Access to the features of SubtleCrypto is obtained through the subtle property of the Crypto object you get from the crypto property." Mozilla says the Web Crypto API is an interface allowing a script to use cryptographic primitives in order to build systems using cryptography.

But First, Blazor Hybrid
Note that Roth said all of the above work was planned for "After finishing Blazor Hybrid support for .NET MAUI, WPF, and Windows Forms." Blazor Hybrid apps are native apps that can leverage web technologies like HTML and CSS for additional functionality. Thus a hybrid app might use an embedded WebView control to render web UI while also leveraging native device capabilities, as explained in last month's Visual Studio Magazine article "Edit Local Images/Text from a .NET MAUI Blazor Hybrid App."

You can read about what's coming for Blazor Hybrid in .NET 7 in the appropriately titled article, "What's Coming for Blazor Hybrid in .NET 7."

Roth's Feb. 17 post about ASP.NET Core updates in .NET 7 Preview 1 says that after that work is done, other improvements for Blazor (in addition to the AOT stuff) include:

• Enhanced Hot Reload support
• Data binding improvements
• More flexible prerendering
• More control over the lifecycle of Blazor Server circuits
• Improved support for micro frontends

Other ASP.NET Core areas up for development investment as outlined by Roth include:

• Performance: .NET 6 contained many performance improvements for ASP.NET Core, and we'll do work to make ASP.NET Core even faster and more efficient in .NET 7.
• HTTP/3: HTTP/3 support shipped as a preview feature in .NET 6. For .NET 7, we want to finish it and make it a supported feature that's enabled by default. In future previews, you can expect to see advanced TLS features and more performance improvements in our HTTP/3 support.
• Minimal APIs: Add support for endpoint filters and route grouping as core primitives for minimal APIs. Also simplify authentication and authorization configurations for APIs in general.
• gRPC: We're investing in gRPC JSON transcoding. This feature allows gRPC services to be called like RESTful HTTP APIs with JSON requests and responses.
• SignalR: Add support for strongly-typed clients and returning results from client invocations.
• Razor: We'll make various improvements to the Razor compiler to improve performance, resiliency, and to facilitate improved tooling.
• MVC: Improvements to endpoint routing, link generation, and parameter binding.
• Orleans: The ASP.NET Core and Orleans teams are investigating ways to further align and integrate the Orleans distributed programming model with ASP.NET Core. Orleans 4 will ship alongside .NET 7 and focuses on simplicity, maintainability, and performance, including human readable stream identities and a new optimized, version-tolerant serializer.

New things in Preview 1, meanwhile, were listed as:

• Minimal API improvements:
  • IFormFile and IFormFileCollection Support
  • Bind the request body as a Stream or PipeReader
  • JSON options configuration
• SignalR client source generator
• Support for nullable models in MVC views and Razor Pages
• Use JSON property names in validation errors
• Improved console output for dotnet watch
• Configure dotnet watch to always restart for rude edits
• Use dependency injection in a ValidationAttribute
• Faster header parsing and writing
• gRPC JSON transcoding

"We hope you enjoy this preview release of ASP.NET Core in .NET 7 and that you're as excited about about our roadmap for .NET 7 as we are!" Roth said in conclusion. "We're eager to hear about your experiences with this release and your thoughts on the roadmap. Let us know what you think by filing issues on GitHub and commenting on the roadmap issue."