Make Blazor WebAssembly apps fully trimmable

[danroth27]

The .NET trimmer statically analyzes your project and removes any unused code. In Blazor we use the .NET trimmer to significantly reduce the publish size of Blazor WebAssembly apps. However, we don't currently use the .NET trimmer to its fullest potential. We currently configure the trimmer in a partial mode, which only trims assemblies that are explicitly marked as trimmable. This typically means that the app assembly itself and many dependencies are not trimmed. This is a conservative setting that optimizes for maintaining functionality over reducing app size.

The default trim mode for the .NET trimmer is to trim everything. This is the mode used by the .NET Native AOT workloads.Analyzers provide warnings if there are code paths in the app that are not safe to trim. Given how sensitive web apps are to download size and load time, it seems like doing full trimming should be the goal for Blazor.

Enabling support for full trimming also is a potential solution to enabling a single project model for Blazor Web Apps that target both server and browser. When you multitarget a project, everything in the project is built for both targets unless you indicated otherwise. This is problematic for browser scenarios because you may potentially bring in dependencies, components, and code into the browser targeted build that are only needed on the server. However, if we could enable full trimming and indicate to the trimmer which components are setup to render on WebAssembly, then the browser build could be aggressively trimmed to remove any unwanted code and dependencies.

Enabling support for full .NET trimming typically means removing any dynamic code path that are based on reflection. We would need to make Blazor apps trimmer friendly by removing this code using techniques like source generators. For example, in Blazor we use reflection as part of the component discovery process and in the render tree builder code generated by the Razor compiler. We're already working on enabling component discovery through source generation. We also have on our backlog to handle component parameters through source generation. There may be other related work items as well.

There is also ecosystem impact of enabling full trimming by default. Many .NET libraries are not setup for trimming and would potentially need to be updated. It will take some time to work through these issues with the Blazor community. Certain features also simply wouldn't work with full trimming. For example, dynamically loading dependencies at runtime that are not known statically. For backwards compatibility, app developers can configure the trimmer to not trim assemblies that are not yet trimmer friendly. We'd need to understand better all the cases that get impacted by full trimming and ensure we provide a reasonable user experience for addressing them.

[SteveSandersonMS]

Enabling support for full trimming also is a potential solution to enabling a single project model for Blazor Web Apps that target both server and browser.

It would be fairer to describe it as a potential aid rather than a solution, since (1) trimming is innately unpredictable - people can't fully reason about what will and won't be retained in general, and (2) it will be extremely common for some large dependencies to be retained even though you know they aren't needed, just because some code you don't control uses it in some branch that you know will never be hit.

[SteveSandersonMS]

There are different milestones on this journey - it might be helpful to distinguish at least the following:

1. Enabling trimming by default for all libraries you consume, not just System.*
2. Enabling trimming by default for your application/RCLs

Only item 2 requires guaranteeing that Blazor doesn't use reflection-based discovery, which would be most of the work. Whereas item 1 would likely yield most of the benefit since the vast majority of code inside your app itself needs to be retained, otherwise you wouldn't have put it there.

[danroth27]

Whereas item 1 would likely yield most of the benefit since the vast majority of code inside your app itself needs to be retained, otherwise you wouldn't have put it there.

There is the case where I have an app with 100 pages but I only want one of them on WebAssembly. The trimmer could remove the other 99 when targeting browser if it had some way of understanding which components are using the WebAssembly render mode.

[SteveSandersonMS]

if it had some way of understanding which components are using the WebAssembly render mode.

That's not possible as long as we have the ability to use @rendermode="..." with an expression evaluated at runtime.

[eerhardt]

since (1) trimming is innately unpredictable - people can't fully reason about what will and won't be retained in general

This isn't true for .NET apps all up. The general rule is: "Is it necessary to make the app work? Then it is retained." The general trimming logic is deterministic.

Now for a Blazor app, answering the question "is it necessary to make the app work?" might not be able to be reasoned about. But the general statement that trimming is innately unpredictable doesn't hold for other .NET apps.

We've made a lot of strides in the trimming warnings (which are ignored on Blazor WASM) to tell developers what code has the potential to break their app. If your app publishes with no warnings, our goal is that your trimmed app behaves the same as your untrimmed app.

[SteveSandersonMS]

This isn't true for .NET apps all up. The general rule is: "Is it necessary to make the app work? Then it is retained." The general trimming logic is deterministic.

I didn't say nondeterministic! It's deterministic as far as a machine is concerned, but low on predictability for human developers. You can't easily keep track of (or even reason about) how your code changes are impacting what will get retained.

We've made a lot of strides in the trimming warnings (which are ignored on Blazor WASM) to tell developers what code has the potential to break their app. If your app publishes with no warnings, our goal is that your trimmed app behaves the same as your untrimmed app.

That's great, and describes avoiding "false positive" removals (if there are no warnings, we probably didn't trim something that is required). For very size-sensitive scenarios like Blazor WebAssembly, the "false negative" cases are an equally big concern - something that the app doesn't need but the trimmer can't identify that. We don't have warnings about those.

[SteveSandersonMS]

There is the case where I have an app with 100 pages but I only want one of them on WebAssembly. The trimmer could remove the other 99 when targeting browser if it had some way of understanding which components are using the WebAssembly render mode.

One other point to add here. I totally appreciate where you're trying to get to - having a single project that just puts all the pages/components together and relies on the build system for figuring out what should and should not be in the WebAssembly build.

However, no matter how much the app is trimmed, that won't change the more immediate issue that the compilation will already have failed if your project tries to compile any components/classes in the WebAssembly build that reference things that can't be referenced (e.g., stuff from the ASP.NET Core shared framework, and probably EF assuming that's strictly excluded from the wasm build). So there already has to be some way to exclude most of the non-WebAssembly-specific code from the original compilation, so the core dev experience still involves separating the two builds more explicitly than relying on the trimmer to do it.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[Perksey]

This issue appeared in this blog post: https://perksey.com/blog/blazor-silkdotnet.html

It is currently a blocker for shipping Blazor support for Silk.NET 2.X (it is likely that Silk.NET 3.0 will work without this however, but there is no release date for this and is still in planning).

[Alan-FGR]

This issue is somewhat blocking us as well.

@Perksey Nice article! As a coincidence I found that on GitHub just a few minutes after you push to the repo because I was searching if somebody else was passing FULL_ES3 in the EmccFlags.