-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET 8 Pre-planning #7565
Comments
Would be nice to see more thoughts and possible roadmap around Wasm/Wasi (understanding there is still lots of spec churn that blocks/determines future of .NET support). |
We have discussed it. I think it is just a when not if. The best way to make that happen sooner is offer scenarios where you think that would be useful and compelling. |
I'm actually just starting to get into this space (watching Wasm vids, reading intro books on Rust, etc.). I'm blown away on what Steve has demoed in this space and see great potential. However, with my limited knowledge on topic I'm more just watching from a distance currently. I think what I struggle with right now is what should we expect from a .NET perspective (again, understanding there is going to be lots of change/innovation as it picks up steam). For example, how will it execute in a Wasm runtime? Can we have a few C# classes that compile down to the Wasm bytecode or is a trimmed down .NET runtime and such required to bundle? And what are some average sizes of .NET code used in the space? I'm more interested in this using with IoT (smaller constrained device). The selling point for Wasm is the compliance on different devices. Does this mean we could run .NET code on smaller devices like ESP32 using something like WAMR? Lastly, I could see some really nifty things come out of this with the work done over in dotnet/iot. But would those current bindings work if using in a bare-metal scenario or will it require Wasm to be running under Linux? Anywhos, this definitely will be an interesting space to watch. Thx |
The dotnet/iot bindings will work as long as we can write a GpioWasmController. One of the huge advantages we have is that our implementation is abstracted and easy to port. Most of the bindings would not notice the difference. I didn't know about the ESP32 implementation. I would worry more about resource constraints (memory, clock cycles). |
Okay. Here are the things I want/love to see in .NET 8 1- Native Support of Python 2- C++/CLI on other platforms 3- FFmpeg 4- HttpClient response time |
I hope .NET 8 main focus will be Blazor.
These 4 are the missing pieces that I think Blazor will need to be used by a wider audience.
|
It would be nice to reconsider Blazor custom directives for .NET 8. While the original proposal targets Razor, it makes even more sense for Blazor. There are built-in directives such as FooAttribute.cs: public class FooAttribute : Attribute, IBlazorDirective {
public FooAttribute(string arg) {
}
} BarPage.razor: @foo "hello world"
<h1>Page title</h1> |
Would love to see (ranked from best):
|
Unfortunately, both Trimmed and AOT compilations have a lot of bugs, so they only work for a small percentage of applications so far |
I hope .NET 8 C#
Although more code can be written to implement it, or a corresponding library can be developed to support it. But obviously, C# has been around for so many years, and no useful library has been developed. This means that this is not an easy job. |
I'd love to see:
|
Targeted AOT compilation for WASM, as well as improved Webpack (and others) JS bundling support. |
Is this issue still relevant or can it be closed? |
Now is a good time to start thinking about what might come next. I've started some issues to that end. Feel free to comment with links to improvements that you'd like to see in .NET 8.
The text was updated successfully, but these errors were encountered: