Missed the Hot Design AMA? The recording is available → Watch now

Wasm 3.0 for .NET Developers

There is big news in the world of WebAssembly: The W3C/Wasm standards groups have been hard at work, and the next iteration is ready for release – welcome to Wasm 3.0. Meant to be the live standard, Wasm 3.0 is already supported in major browsers and has deep consequences for app development platforms. Much of the benefits of Wasm 3.0 are speculative at this point, depending on adoption and .NET leveraging the features – but, let’s explore some highlights as they stand now.

Modern .NET is powerful, open-source, cross-platform and welcoming to all, with mature tooling accompanied by rich ecosystems. While .NET has broad platform reach, web browsers have been a challenge – modern web apps deserve to run fully disconnected and entirely client-side with rich user experiences. The best solution is WebAssembly – an open standard enabling high-performance execution of code in modern web browsers.

WebAssembly (Wasm) is a low-level assembly-like language with a compact binary format that runs with near-native performance in modern browsers. WebAssembly is a way to have higher level languages to be compiled down into binaries that can run on the web – Wasm is also designed to run alongside JavaScript, allowing both to work together in today’s browsers.

Uno Platform is the most flexible open-source platform for cross-platform .NET development, complete with enterprise-grade tools. Uno Platform allows for building native mobile, web, and desktop applications from a single shared codebase and Uno Platform Studio steps up the game with unprecedented .NET developer productivity. With Uno Platform, the same C#/XAML .NET code runs seamlessly in native platforms, as well as, on the web through modern browsers. Wonder what the magic sauce is – yep, it is WebAssembly, with carefully crafted pixel-perfect UI rendering.

64-Bit Memory

Memory allocation for Wasm apps goes up from 32 to optional 64-Bit – this increases available address space for WASM from 4 GB to the extent that physical hardware allows. While web browsers might still have limits, the increased memory footprint for Wasm apps should open up lots of possibilities.

Here are some benefits:

– Richer UI & UX for Wasm apps in/out of browsers

– Apps have access to much larger in-memory footprint

– Allows larger enterprise apps to be hosted entirely in the browser

– Quicker app loading and improved performance with faster memory processing

JS string built-ins

JavaScript runtimes have a rich set of built-in objects and primitives – languages targeting WebAssembly may have compatible primitives and would benefit from being able to use the equivalent ones in JavaScript for their implementation. The most pressing use case is for languages like C# to avoid excessive byte-copy from JS strings to .NET strings – Wasm 3.0 now enables this.

Here are some benefits:

– JS string are easy to interop with .NET strings

– Faster interop avoiding lots of string copying

– Avoid importing ‘glue’ mechanism for large primitives like String

Garbage Collection

Wasm 3.0 brings enhanced memory management – there is now support for a new form of storage that is automatically managed by the Wasm runtime via a Garbage Collector (GC). Higher level programming languages can declare needed memory layout for runtime data structures, whose allocation and lifetime is then handled by Wasm. By design, there are no built-in object systems or higher-level constructs as they inevitably get biased towards specific languages – instead Wasm runtime only provides the basic building blocks for representing memory and consequent cleanup. It should be noted, however, that WasmGC support in .NET is unlikely to happen any time soon – it is missing some key pieces that the .NET semantics require and work is ongoing. Developers are encouraged to follow/vote/voice opinons on the GitHub issue.

Here are some benefits:

– Easier hyrdation/dehydration of memory constructs used in Wasm apps

– No memory leaks with built-in GC

– Managed allocation/recoup of runtime memory constructs

Typed References

The Wasm type system now supports much richer forms of references – reference types can now describe the exact shape of the referenced heap value, avoiding additional runtime checks that would otherwise be needed to ensure safety. This more expressive typing mechanism will be available to higher level programming languages towards safe function references, thus reducing runtime type or bounds checks. With .NET already leveraging typed references in Wasm, this would mostly enable easier interop with other languages.

Here are some benefits:

– C# can have richer mapping to WASM typed references and better interop with other languages

– WASM apps can manage state better with type safe object handling

– Faster execution of WASM code by browsers

Exception Handling

Debugging Wasm apps will get better with Wasm 3.0 bringing in support for native exception handling – Wasm can now bubble exceptions up the chain in a robust way, paving the path for smoother debugging. With .NET leveraging Wasm exception handling since .NET 8, developers can expect more streamlined performance and continued debugging experiences.

Here are some benefits:

– Easier debugging of C# code when running in Wasm

– Better runtime performance and management of exception handling within bounds

– Clearer jump off points and recovery when exceptions happen

Wasm with Uno Platform

WebAssembly allows .NET code, and hence Uno Platform code, to run natively on the web – it is supported by all major browsers, including mobile browser versions. Wasm in the browser runs in the same security sandbox as JavaScript does, and has exactly the same capabilities and constraints – all communication to and from the Document Object Model (DOM) must be done by interop with JavaScript. There are lots of success stories of Uno Platform enabling .NET apps to run smoothly in browser through Wasm – the likes of Windows Community Toolkit Gallery, Nuget.info, Calculator app and many more.

.NET web apps can run as Progressive Web Apps (PWA) with some orchestration, but PWAs often fall behind in performance compared to native apps and need additional engineering for pixel-perfect UI. While Blazor does run in WASM mode, Blazor is meant squarely for web apps without much code sharing – for .NET developers, Uno Platform is the only cross-platform way of leveraging Wasm as a true target platform from a shared codebase serving native apps as well.

Let’s take a look at a sample Uno Platform Counter app – once pulled down from GitHub repositories, developers can tinker with the codebase in Visual Studio/VS Code/Rider across Windows/macOS/Linux. As long as the Target Framework Moniker (TFM) in the project .csproj includes the net9.0-browserwasm target, the same shared codebase will power the .NET app to run in the browser – Wasm coming into play here:

Hot Design in Uno Platform Studio is the next-generation Visual Designer for cross-platform .NET apps. Hot Design transforms a running .NET app into a Designer from any IDE on any OS – this creates synchronized design and runtime experiences with live data to eliminate back-and-forth. And yes, Hot Design works in the browser in Wasm mode – developers get to tinker with UI while the app is running, and get .NET code generated that is saved back in the IDE.

Since the .NET app is running entirely in the browser through Wasm, DOM elements are perfectly inspectable with browser developer tools. It is to be noted that Uno Platform uses SkiaSharp to render much of the app UI – DOM elements are mostly structural

Parts of the .NET/Uno Platform runtime that renders the app in Wasm mode are all loaded up in browser and inspectable as well:

Debugging C#/XAML code while the app is running in Wasm mode is also possible – doable with Visual Studio or in browser, if workspace is allowed access to .NET code:

There are some unique differentiators to the way Uno Platform makes .NET apps run in the browser through Wasm:

Uno Platform renders XAML/C# UI elements onto Wasm through DOM integration and streamlined Skia rendering pipeline
Developers have more confidence in pixel-perfect UI rendering with SkiaSharp between native platforms/Wasm targets
Uno Platform runtime for Wasm is defined in Typescript and does the heavy lifting, so .NET developers need not care about rendering details
JavaScript interop is the way to manipulate DOM elements and access other browser APIs from WebAssembly
C# can invoke JavaScript and JavaScript can invoke C#
The Uno.Wasm.Bootstrap package provides a runtime bootstrapper for Microsoft.NET.Sdk.WebAssembly SDK from .NET 9
With breaking changes in .NET 9, WebAssembly threading is currently not supported in Uno Platform – work is ongoing to bring it back for future Uno Platform iterations

Conclusion

WebAssembly (Wasm) continues to evolve as a standard and is the de-facto way of running higher level code natively in the browser. Wasm 3.0 specifications bring a wealth of benefits to streamline even better runtime performance and interop with programming languages like C#. Developers will benefit knowing the nuances of Wasm 3.0, but the runtimes will do much of the heavy lifting to leverage latest memory/performance enhancements – smoother apps lead to happier user experiences.

With Uno Platform, modern .NET developers have all the ammunition to go build the next amazing cross-platform app and leverage the latest in WebAssembly to run the same app seamlessly in modern browsers.

Cheers developers!

Next Steps

Ready to boost your productivity and simplify cross-platform .NET development? Try Uno Platform today by downloading our extension for your preferred IDE and join our developer community.