jeromelaban
commented
2 years ago For those tracking this issue, threading and exception handling are making progress in the runtime, the issue description has been updated.
Open jeromelaban opened 4 years ago
jeromelaban
commented
2 years ago For those tracking this issue, threading and exception handling are making progress in the runtime, the issue description has been updated.
WebAssembly Key Missing Features
Interface Types support, to avoid going through javascript, at all. It would give access to the DOM, WASI, and others to create very performant code. This goes along with Wasm GC support, which would place mono in a very similar position to X.I or X.A, and require bridges like Tarjan.
Memory release support https://github.com/WebAssembly/design/issues/1397
.NET Runtime Features
SDK Binaries Distribution. Current distribution is done though explicit Url capture of the CI’s artifacts. This makes for a very fast pace of evolution, but could also be a problem in the future, with versions of the Uno.Bootstrapper (and others) using discarded mono CI artifacts. The AOT toolchain is particularly large (zipped, the whole SDK weighs 210MB, without macOS binaires). Update 2020-11-23: This is being worked on with .NET 6, where the SDK will be distributed through nuget. Current .NET 6 builds nuget packages are around 70MB zipped. Update 2021-08-29: The bootstrapper still uses its own build of the runtime, but is less heavy (~40MB) that it was with mono. It's currently distributed through a CDN, but should be migrated ultimately to be a nuget package.
MSBuild-based toolchain, compatible with Windows and macOS. It would be a toolchain that is exposed through msbuild, without having to resort to the use of the packager explicitly.
For now, only linux is fully supported, because the CI’s artifacts only contain working Linux binaries.Update 2020-11-23: This is being worked on with .NET 6, where the SDK is now including MSBuild tasks to replace the mono packager. Update 2021-08-29: The bootstrapper still uses its own packaging, but the runtime tooling is maturing quickly. It is still very much blazor aligned, but likely will be generalized for .NET 7. Windows build is now supported.Released
Profiling, to allow for the same kind of performance investigations available in X.I or X.A. For now, profiling is only realistic in AOT, but does not highlight slow paths under the interpreter. This makes mixed mode scenarios difficult to troubleshoot and optimize.Update 2020-11-23: Profiling inner workings are available in the runtime, though nothing exposes it it properly in net6. Update 2021-08-29: Profiling is now available in .NET 6, see the bootstrapper documentationProfile-based mixed mode, similar to the startup tracing in Xamarin.Android.Update 2020-11-23: This is now available as part of the 1.3.x bootstrapper for mono, also in the boostrapper 2.0.Nuget integration. Addition of a “runtime” entry would be very useful. Mono itself will have this problem very soon with the wasm-specific types (Bindings, HttpClient, WebSockets, etc…) for which there is no easy way to reference in nuget packages, or even in the main binary.Update 2020-11-23: This is not a concern anymore, as the .NET team does not mentioned it will not be supported, but that thenet-browserruntime ID is available. As far as uno is concerned, cross-target libraries handle this using unoruntime folders in nuget packages.Full VS Debugger experience, the ability to debug a mono-wasm app from VS, without having to jump through the current debugger proxy hoops. This also includes a more advanced debugging support, with watches, globals support, and interpreter stacktrace unmangling.Update 2020-11-23: This is available as a preview in VS 2019 16.8 and later.Threading, pthreads via emscripten support for all browsers. This is available in the new Edge and Chrome, flagged in Firefox, not implemented in Safari. This was a work in progress in mono, descoped for .NET 6. Will likely be worked on for .NET 7.Update 2022-11-04: Available in Bootstrapper 7.0Exceptions support, to avoid the back and forth with javascript. This is particularly expensive at runtime when using the try/finally construct, which is used extensively in the BCL. It also most probably impacts the package size.Update 2022-11-04: Available in Bootstrapper 7.0