WebAssembly and .NET
WebAssembly has become a hot topic over the past couple of years, but you may wonder what exactly it is and why you might want to use it. JavaScript has long ruled Web Development, and the popularity of web frameworks like React and Angular have done little to change that (since they are using JS too). Even an alternative language like Microsoft's TypeScript is ultimately transpiling into JavaScript to run in-browser. Years of browser and language optimizations have done much to improve JavaScript to the point where even 3D gaming engines are able to run in browser using JavaScript. So why consider an alternative? Though JavaScript is pervasive there has always been criticism of the language, and many are now hopeful that they'll finally be getting an alternative with WebAssembly.
What is WebAssembly?
WebAssembly (Wasm) is a new binary format language for a stack-based virtual machine that is supported in modern browsers (Firefox, Chrome, Safari, and Edge). A large part of the appeal is that it's a portable compilation target for other high-level languages like C, C++/, and C#. It aims to be fast (at near native speeds), memory safe and sandboxed since it executes within a VM, and an open standard for others to use.
The concept of Wasm isn’t so different from .NET bytecode, and the instructions operate at a lower level than JavaScipt on native machine types for efficient compilation. The code should also be small and compact making it easier for browsers to download and load web apps. While JavaScript is supported in more places, there have also been prototype polyfills that convert Wasm to asm.js for platforms that don't have built-in Wasm support. Modern browsers already have support for Wasm.
Why use WebAssembly?
There are several reasons why WebAssembly is appealing to developers. It has the possibility of being faster and more compact than JavaScript, and some developers will be drawn to it for its performance characteristics. Some things that are awkward to express in JavaScript (like threading) will also be much easier to potentially implement here. Finally, the biggest factor for most developers is that it opens the possibility of using other high-level languages for doing web development. For .NET developers this means that it might be once again viable to primarily use C# in your web app, though this technology isn't limited to Microsoft platforms as it already supports C and C++.
Keep in mind that Wasm is most likely to be a complement to JavaScript rather than a replacement. It's likely that developers will leverage it for certain high-performance modules, but still maintain JavaScript outside of those components. Even fully compiled Wasm apps will likely have some JavaScript to help stich a web page together.
Just within the .NET community there are currently 3 major technologies leveraging Wasm including Blazor, Uno, and Ooui. Each of these have their own niche,and they will interest developers for different reasons.
Blazor
Blazor is an experimental .NET framework that originates from the ASP.NET team that allows you to create a web application using C# and Razor syntax. In some ways it's almost like a replacement for some web frameworks (like Angular) that are ASP.NET Core centric. It's likely to appeal to developers who have used ASP.NET Web Forms and MVC (or dare I say it… Silverlight).
Blazor has a much gentler learning curve for those groups compared to learning Angular or React. Also, since it's Wasm-based, it can run fully in the browser. This technology is backed by Microsoft and is actively being developed by the ASP.NET Team. It's open-source, free, and uses .NET Standard. While still experimental, it's likely to have the brightest future of the .NET Wasm technologies and it will ship as part of ASP.NET Core 3.0.
Uno
Uno is an interesting cross-platform solution that allows you to write C# and XAML code for mobile and web using a free UWP bridge. Uno's technology leverages both Mono (for mobile) and Wasm for web. Apps can be written in a similar style to UWP XAML, and your XAML is parsed to C# and further compiled into Wasm. It doesn't require much from a XAML developer, as it allows them to reuse many of their existing skills for databinding, control and data templating, MVVM, etc. There is an online demo available that gives you some idea of how this works that lets you modify XAML in browser to configure a selection of UI controls. The technology is still early, but it's undeniably cool tech and should appeal to desktop XAML developers.
Ooui
Ooui is another cross-platform .NET UI library that enables Wasm using XAML and C#, though in this case it's using Xamarin.Forms as its base. The specific appeal of this library is that it can be used with Xamarin.Forms (which is code that was already explicitly cross-platform), and it enables existing Xamarin apps to potentially be extended to web. This project is also relatively early, but it has a number of samples that illustrate its possibilities.
What's Missing
There are some missing features eventually coming to Wasm that will make it more compelling to developers. Low-level pthread style threading and shared memory haven't been added yet, though they are on the roadmap. Garbage collection is another huge feature that many C# developers have come to expect since it makes memory management much easier. Not many enjoy going back to C style memory allocation and deallocation.
There are many other import features listed on the features roadmap for post MVP (minimum viable product) like Exception handling and SIMD support. WebAssembly 1.0 was their MVP release and since we're now in the post MVP era, many of these features are being actively worked on. Supporting these features would enable a more complicated class of heavyweight application development which Wasm would be uniquely qualified for (provided they're able to ship these features in a timely fashion).
WebAssembly Wrap-up
Though WebAssembly is several years old now we're still in the early stage of its existence, and it's not immediately obvious how it will evolve in the future. It's likely to be popular though (it's already a big conversation topic), and new projects will likely start using it in the coming year. Though we've focused on the .NET side of Wasm, it's likely other languages use it too. Rust, Java… really anything is possible provided developers are dedicated enough to build the tooling for it. At this stage it's hard to predict which flavors of WebAssembly platforms will be the most popular, but it seems very likely that many developers will take advantage of it in the future.
