This is a bit of an epic article (24 min read time), but very much worth it. Marcel works for Micrio, a story-telling platform that allows users to create ‘deep zoom’ experiences with narrative. Performance, and a wide-ranging browser support are very important for this commercial tool.
I must admit, I’m not keen on the approach of Base63 encoding and inlining wasm modules to create a single bundle. One of the key features of WebAssembly is its binary format which is fast to load and decode. Base64 encoding makes thee whole process slower and more bloated! Anyhow, a fantastic article, and well worth a read.
From one WebAssembly-specific language (AssemblyScript), to another! Whereas AssemblyScript is a designed to be a very close relative to TypeScript, Grain is an entirely new language built specifically for WebAssembly. Grain is a ‘relaxed’ functional language, it is statically types an has many of the functional features that are growing in popularity, however, it also supports mutability. This blog post reflects on the current state of the language and what the future holds.
Python is the language most often used for AI and data science, however, for computationally intensive tasks it tends to use native C++ modules. This article proposes using WebAssembly as an alternative wrapper or host for these AI algorithms, looking to create a “real-world AI as a Service use case in Node.js using Rust and WebAssembly”.
Currently Blazor WebAssembly works in an interpreted mode, a wasm .NET language runtime is shipped to the browser allowing it to interpret .NET assemblies. In the future the team hope to implement Ahead Of Time (AOT) compilation, removing the need to ship the runtime, however, this will not be ready for another year. In the meantime, the team or committed to making the current implementation of Blazor much faster. This blog post covers some of theses recent enhancements and performance gains.