Microsoft's Miguel de Icaza Ponders New Use for WebAssembly
Miguel de Icaza doesn't post to his personal blog often, but when he does, developers listen.
The Xamarin guru's newest post, about 11 months after the previous one, is about a new way to use WebAssembly, the technology backing the client-side effort of Microsoft's red-hot Blazor project that allows for C#-based web development.
Developers listen to de Icaza because he has a resumé unmatched in the industry, having started GNOME and Mono in addition to Xamarin and other projects.
After Microsoft acquired Xamarin, he was finally hired by Microsoft in 2016, completing what he described as "longest job interview of my career."
Blazor has garnered attention in the Microsoft-centric development world because, as de Icaza has said, it provides "a new approach at building interactive web applications with C# by bringing some of the easiest to use and most-loved patterns of web development to .NET."
But it turns out WebAssembly can be used for other rendering targets beyond the web, including Progressive Web Apps (PWAs), mobile, desktop and more, and one such a new direction is the focus of his new post, "Scripting Applications with WebAssembly."
Speaking to those non-web use cases, de Icaza said, "Outside of the web browser domain, WebAssembly checks all of the boxes in my book:
- Provides great code isolation and memory isolation
- Easily discard unused code and data
- Wide reach: in addition to being available on the Web there are runtimes suitable for almost every scenario: fast JIT compilation, optimizing compilers, static compilation and assorted interpreters. One of my favorites is Wasmer
- Custom operations can be surfaced to WebAssembly to connect the embedded code with the host
- Many languages can target this runtime -- C, C++, C#, F#, Go, Rust and Swift among others"
In his post, WebAssembly's benefits are characterized in the context of code hot reloading -- where the effect of code changes can be observed immediately -- in scripting-capable applications such as the Unity3D game engine. De Icaza envisions development workflows in which WebAssembly is used in the development of scripting applications to provide hot-reloading of code, but is left out of production builds.
Referencing a Unity-based scenario, he said, "the fascinating feature for me, is that IDEs/Editors/Tools could leverage WebAssembly to host their favorite language for scripting during the development stage, but for the final build of a product (like Unity, Godot, Rhino3D, Unreal Engine and really any other application that offers scripting capabilities) they could bundle the native code without having to take a WebAssembly dependency.
"For the sake of the argument, imagine the Godot game engine. Today Godot has support for GodotScript and .NET. But it could be extended to support for Swift for scripting, and use WebAssembly during development to hot-reload the code, but generate Swift code directly for the final build of a game."
Furthermore, the post serves to add yet another new use case scenario for the technology backing Blazor, in addition to mobile, desktop, native and other such potential rendering targets. "WebAssembly is an incredibly exciting space, and every day it seems like it opens possibilities that we could only dream of before," de Icaza said in conclusion.
David Ramel is an editor and writer for Converge360.