We shipped the first fully .NET Core based version of WebAssembly for Blazor in .NET 5. We had to make a few compromises and cut several features to meet the deadline. One of the major features postponed from .NET 5 was AOT support for WebAssembly. We want to keep investing and improving WebAssembly support to make our .NET solutions on the web complete and competitive.

Goals

Native WebAssembly / AOT Support

We have customer evidence and have done our performance measurements of Blazor scenarios. In several areas, there is a large gap between client and server performance which limits the potential of the .NET WebAssembly platform to be used for a broader range of applications. We have improved performance for several scenarios in .NET 5 release but many of them remain to be much slower compared to our server implementation or JavaScript frameworks.

Web Cryptographic Support

The .NET APIs have been designed with the desktop mindset first. For that reason, we had to make few critical APIs not supported when running .NET inside the browser in .NET 5 release and made libraries like Azure Cosmos DB which need cryptographic support to do add extra compatibility code to work inside the browser. We need to revisit that decision as it makes the migration between server and client Blazor more complicated and adds fragmentation angle to .NET ecosystem. We will focus on bringing cryptography support to WebAssembly in the way it's compatible with other .NET workloads.

Smaller Globalization Dependencies

Globalization libraries typically add significant size to applications. Globalization invariant mode enables developers to ships smaller apps, but offers essentially no globalization support at all. Globalization invariant mode could offer more functionality, with a fraction of the size required. We’ve talked about doing this for Wasm and Docker. We need to determine if we can decide a cluster of globalization functionality that solves customer problems and that appeals to at least some regions.

General App Size Reduction

In Blazor scenario reducing app size in every new version is equally important to the developers as the performance improvements we make. We regressed the final size for most of these apps in .NET 5 compared to Blazor 3.2. In the next release, we are aiming to reduce the final compressed size for typical Blazor workloads by at least 20%. We'll need to keep in mind that if we enable AOT support for wasm by default in, the size is likely going to grow not to shrink and more mitigations will need to be put in place.

Unmarshalled interop

When running on Blazor WebAssembly, it's possible to make unmarshalled calls from .NET to JavaScript. These are synchronous calls that don't perform JSON serialization of arguments or return values. All aspects of memory management and translations between .NET and JavaScript representations are left up to the developer. While using unmarshalled interop has the least overhead of the JavaScript interop approaches, the JavaScript APIs required to interact with these APIs are currently undocumented and not officially supported. Various users have reported that these APIs are absolutely required to satisfy their requirements. For .NET 6 we will finalize these APIs and document unmarshalled interop as a supported feature.

Users Stories

• Developers can AOT compile .NET apps into WebAssembly format #44316
• User Story: WebAssembly developers want smaller published output to speed up their apps load time #44317
• Developers targeting browser-wasm can use Web Crypto APIs #40074
• User Story: Developers need more flexibility for globalization settings to fulfil their needs on the web #44321
• Developers need faster interop between JavaScript and C# to be able to port large apps to webassembly #44330
• User Story: Developers can easily use NuGets with native libraries to build fast wasm projects #44636
• Blazor client developers can use Parallel.For in their applications to share more code with server #43411
• Developers can employ EventSource APIs when publishing for AOT targets to be able to use .NET tracing capabilities #43390