Epic: Expand .NET WebAssembly Capabilities #43767
Comments
marek-safar
added
the
User Story
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Dotnet-GitSync-Bot
added
the
untriaged
lewing
added
untriaged
|
Can we add Blazor to the title? |
|
@marek-safar should make each of the sub issues into User Stories so they can get individual costs and maybe priorities. |
|
@samsp-msft WebAssemly != Blazor so I'd keep it this way as it has a broader impact. @danmosemsft I think it'd be better to make this item Epic |
|
@marek-safar fine, but I think it needs child user stories - I don't see how we can cost this as a whole. |
|
@danroth27 are you the PM for this one? |
|
@danmosemsft Yup |
marek-safar
added
Epic
marek-safar
changed the title
|
Tagging subscribers to this area: @CoffeeFlux |
|
Changed the link for the Blazor source generators as it was moved to aspnetcore repo. |
|
Given the Epic's top description of improving performance compared to backend execution .Net Core performance, I'm somewhat surprised you're not doing work to enable this in Blazor: (or maybe you are and I'm missing it?) |
|
@RChrisCoble Much of the work to support multithreading in .NET on WebAssembly has been done, but browser support still isn't fully available. Safari in particular hasn't reenabled support for shared array buffers yet. How useful is multithreading support for your scenarios if it only worked in Chromium based browsers, and not Safari? |
I replied to your Microsoft email directly for this response, as it requires divulging future release dates and intended scope. Thanks for the follow up, greatly appreciated! |
|
This may be outside scope but would love the ability to interop in some way to WASM from .net code (all of the above goals are really targeting scenarios where .net code is running in a WASM environment). There are some community projects out there experimenting with this this through WASM->CIL conversion. Since many languages now compile to WASM it would make importing JS / Rust / Go / etc libraries possible with some work. |
|
@plaisted this is already possible: https://jaylee.org/archive/2020/03/22/csharp-interop-with-c-cpp-and-rust-in-webassembly.html, through p/invoke. This is what SkiaSharp uses, same for SQLitePCL. |
|
I was under the impression that only worked when running in a mono webassembly environment... I'll dig in again and take a look. My suggestion was to be able to effectively P/Invoke a WASM binary while running under net core (or transpile it to a DLL ahead of time and then import as normal). |
|
It's running as well in a net6 environment, though the current tooling in main does not allow for it. I added that support in the uno wasm bootstrapper and it works for both mono/mono and dotnet/runtime. |
|
Thanks for the link and the article @jeromelaban - did you ever get to write the follow-up "how to use strings back and forth in both environments"? |
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsWe 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. GoalsNative WebAssembly / AOT SupportWe 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 SupportThe .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 DependenciesGlobalization 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 ReductionIn 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 interopWhen 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
|
ghost
locked as resolved and limited conversation to collaborators
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 need faster interop between JavaScript and C# to be able to port large apps to webassembly #44330Developers can employ EventSource APIs when publishing for AOT targets to be able to use .NET tracing capabilities #43390The text was updated successfully, but these errors were encountered: