Open javiercn opened 11 months ago
/cc @danroth27
Related issue tracking enabling full trimming: #49409
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
I'd like to see trimming and AOT as two separate goals. That way we can deliver value for folks wanting to use both CoreCLR and native AOT runtimes. In fact, I suspect we'd get more users for this work if it was productized for CoreCLR as well.
Please prioritize trimming over AOT. I assume it is a prerequisite for AOT anyway. I have lost several Blazor projects to other tech due to lack of trimming. Iot, CLI UI, tooling, vscode plug-ins, k8s...
Hey @maloo, can you elaborate a bit more? Sounds like you've got some great feedback. Also what do you mean by "CLI UI"?
@richlander I just meant that step one should be to support trimmed Blazer Web apps. I assume that will be a requirement for AOT apps anyway, but first supporting trimming would enable new use cases before having to fix things like runtime generics that can work with CLR but not AOT. I do a lot of LOB stuff with C# for clients. And in many use cases (listed above) size is more important than AOT. Jit is fast enough in most cases (though I would prefer it for CLI apps). But it is easy to loose these use cases to go, rust, c++ etc when your app is in the 100MB size instead of 10MB. It just looks bad and sometimes that is enough to loose the project. By CLI UI I mean the ability to have a CLI tool that can open upp a UI in a browser. You could do that with gui.cs, but that is way more limited than a Blazor UI. Another thing is that LOB apps are often shared by email, which is hard without trimming... Another mentioned use case is a native service for vscode (common in many dev companies) where you need complex UI in vscode. But to make it easy for user you want to bundle the server process (Blazor app) in the extension installer, again size matters when compared to other solutions.
Somewhat related to CLI UI, I think it was a big oversight to stop Steve Sandersons webview2 app. It would have opened up lots of new use cases. Again size matters, so MAUI is way overkill/bloat (and no trimming I guess) when all you want is a native html view for your Blazor app. Photino should be a part of Blazor in .NET to solve the desktop and cross platform UI gap in .NET after MAUI failure. https://www.tryphotino.io/
will this also cover the WebView
component to be native aot friendly? it seems that native aot wont work on libraries like Photino.Blazor which uses that component.
will this also cover the
WebView
component to be native aot friendly? it seems that native aot wont work on libraries like Photino.Blazor which uses that component.
@ivanjx No, this issue is specific to Blazor web apps (although there may be some overlap with the work). For Native AOT support for the various BlazorWebViews I recommend opening a new issue in the dotnet/maui repo.
There are several issues around this topic, and none are very explicit.
This issue will track the work we need to do to make this happen.
AoT has become an important tech across the industry, with emphasis on cloud scenarios, performance and "leanness". As such, it's interesting for Blazor Applications (a subset at least) to be able to be compiled ahead of time.
AoT opens the door to new scenarios, such as:
It also enhances Blazor's ability to run on existing scenarios:
In general, AoT brings in the following benefits:
Goals/Scope of the work
Reasoning
We only get the benefits of AoT if we remove all the blockers, so we want to reduce the cost as much as possible by making changes that provide immediate value for other reasons (perf, trimming, etc).