🕓 7 MIN Over 90 improvements in …
Menu
In this article, I will look at the current state of WebAssembly (wasm). I’ll start by revisiting 2022 developments to see if any of my predictions came true and if there were any surprises. Then I’ll try to predict where I think things will go in 2023.
In 2021, Safari surprised me with how much work went into catching up to the other browsers’ WebAssembly support. So how did Safari do over the past year?
Safari has continued to improve its WebAssembly support by implementing several bug fixes and improvements, but most of its visible work went into improving the browser in other areas. Although there weren’t prominent wasm features implemented this past year compared to what happened the year before, a lot is happening under the hood.
For example, in last year’s prediction, I thought fixed-width SIMD was something that Safari would implement in 2022 and round out browser support for it. Unfortunately, fixed-width SIMD didn’t make it into Safari in 2022, but it’s now complete and part of Technical Preview 161!
Update: Safari added support for WASM SIMD on March 28th, 2023. See Safari 16.4 Support for WebAssembly fixed-width SIMD. How to use it with C# to learn more.
SIMD (Single Instruction, Multiple Data) is a type of parallel processing that takes advantage of a CPU’s SIMD instructions to perform the same operation on multiple data points simultaneously. This process can result in significant performance gains for things like image processing. Because there are multiple types of SIMD, fixed-width 128-bit SIMD operations were chosen as a starting point.
Another area where Safari picked up the gauntlet in 2022 is with the Tail Call feature, which is also now in Technical Preview 161. This has been sitting behind a flag in the Chrome browser for some time now and couldn’t move forward until the specification reached phase 4 (standardization). For the specification to move to phase 4, at least two web VMs need to support the feature, so another browser, Safari, in this case, needed to implement it.
Tail calls are useful for compilation optimizations and certain forms of control flow, like recursive functions. The following article explains how tail calls work with recursive functions to prevent stack exhaustion: https://leaningtech.com/fantastic-tail-calls-and-how-to-implement-theNote:
Chrome and Safari added WebAssembly exception handling support in 2021 but it was still being worked on in Firefox by year-end. In May 2022, Firefox rounded out browser support for this feature allowing modules to include exceptions without worrying about the performance hit, or the increased code size, that existed with JavaScript’s use as a workaround.
Tooling was quick to jump on this feature. In 2022, .NET 7 and Uno Platform both added support for WebAssembly exception handling as well as SIMD. Uno even went a step further and added experimental support for WebAssembly threading.
Currently modules can only have one block of memory. If the module needs to communicate with JavaScript, or another module, by allowing direct reads and writes to its memory, it risks information being disclosed or accidentally corrupted. This proposal would allow a module to have multiple memory blocks where a module could do things like keep one block for internal data while exposing another block for the sharing of information. There are a number of other use cases defined here if you’re interested in learning more: https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md.
This was a feature that I was hoping for in 2022 because I see a lot of uses to having multiple blocks of memory. Unfortunately, I don’t see it being worked on by any of the browser makers at this time.
Garbage collection is needed by a number of managed languages. Because WebAssembly doesn’t yet have garbage collection, languages that need it had to either include their own garbage collector or compile their runtime to WebAssembly. Both approaches result in bigger download sizes and a slower startup time especially if it isn’t cached yet.
The garbage collection proposal for WebAssembly was created back in 2017 but it’s been at phase 1 ever since. Over 2022, I was pleasantly surprised to see this proposal move to phase 2 in February and then to phase 3 in October!
All browser makers are building in support and there are already efforts to adjust the compilers for several languages to take advantage of it.
When WebAssembly was released as an MVP in 2017, it was considered 1.0. Since then a number of WebAssembly features, like the fixed-width SIMD proposal mentioned earlier, have been standardized.
In 2022, a version 2.0 of the WebAssembly specification was started. This is basically a way of saying that, if a runtime supports WebAssembly 2.0, it supports all of the standardized features that are a part of it.
The details on the following page are a bit low-level but the list of proposals that make up the changes since 1.0 are listed at the bottom: https://webassembly.github.io/spec/core/appendix/changes.html
Aside from the WebAssembly feature proposals and their implementations, this is an item I view as being a significant game changer: WebAssembly modules that can be run by your container engine and can run side-by-side with your existing containers!
Containerd is a container runtime that is used by several container engines like Docker and Kubernetes. A change was made to allow containerd to use a wasm shim and then have that shim use a wasm runtime to run WebAssembly modules.
With this change, you’ll now be able to leverage your existing container infrastructure to run WebAssembly modules. Wasm modules have no access to the underlying system by default bringing added security. Wasm images are also smaller and start faster than traditional images. Another advantage to this is that you’ll be able to use container repositories like Docker Hub to share your WebAssembly images.
The following article has some examples of running Wasm in Docker: https://docs.docker.com/desktop/wasm/
Microsoft has also released a preview of AKS that runs WebAssembly: https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-pools
A lot of work has gone into JavaScript over the years to make it really fast in the browser but, like with many developers wanting their languages to run in the browser too, JavaScript developers also want to run their code outside the browser.
When it comes to things like edge computing at scale, how quickly your JavaScript code starts running matters. With V8 isolates, startup time is now in the millisecond range but experimentation is happening to see if that can be improved.
The Bytecode Alliance (the group working on the WebAssembly System Interface or WASI) has taken the Firefox JavaScript engine, SpiderMonkey, and compiled it to WASI. Then they used a clever technique by having a build step that runs the JavaScript code and then takes a snapshot of the initialized bytecode held in linear memory. That snapshot is stored in the data section of a module and all that pre-initialized data is just dropped back into linear memory as needed by the engine, speeding up initialization time dramatically (0.36 milliseconds or 13 times faster in their example). More details on this experimentation can be found here: https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly
The SpiderMonkey engine being available as a WASI module means that JavaScript could potentially be embedded in even more systems and run just as fast as it would in a highly optimized web browser.
As of January 12th, fixed-width SIMD is in Safari as part of Technology Preview 161. This will round out browser support for this feature when Safari 16.4 is released in the next month or two.
Also included with the Safari Technology Preview 161 release is the tail call feature. With that, the WebAssembly tail call specification has already moved to phase 4.
Chrome was waiting on the specification to move to phase 4 before bringing tail calls out from behind a flag. Now that it has changed phases, we’re likely to see tail calls released in Chrome and Edge in the coming months.
Firefox is working on implementing tail calls and will hopefully release support in the near future to round out browser support.
Now that the garbage collection proposal has reached phase 3, all browser makers are building in support.
What’s also exciting is seeing that several programming languages like Java, Kotlin, and Dart are already working towards taking advantage of this new feature.
I’m not sure if this is something that will be fully released by browsers in 2023 but I could see portions of it being released, or possibly having it behind a flag, so that toolchains can start playing around with it.
With Docker’s WebAssembly support now in beta, and with providers like Azure AKS previewing support, I think that containers will help wasm use explode outside the browser. Being able to use existing infrastructure and services already in place, and the ability to share WebAssembly images in repositories like Docker Hub, are big advantages.
There are quite a few WebAssembly proposals in the works but some of them are already in the Chrome and Firefox browsers behind a flag so I’d think they’re high possibilities for release in 2023. These include: Memory 64, Relaxed SIMD, and Type reflection.
The JavaScript Promise Integration proposal sounds quite useful where the module can continue to be built to call functions in a synchronous manner but the browser would pause the module’s execution while it waits for an asynchronous call to complete. More information on this proposal can be found here: https://v8.dev/blog/jspi
With many of the core WebAssembly features now cross browser and more advanced features joining the list like exception handling, tail calls, and garbage collection, I think we’re going to see more languages target WebAssembly and existing tooling improve.
WebAssembly is still a small amount at around 2% of Chrome users, but there has been a steady increase in its use on the web. Even at 2%, that’s still a pretty big amount given the size of the web. The web usage metrics can be found here (click the ‘Show all historical data’ checkbox): https://chromestatus.com/metrics/feature/timeline/popularity/2237
There appears to be a lot of adoption of WebAssembly outside the browser in areas like serverless providers and streaming services like Disney and Amazon. I’m hopeful that we’ll also start to see more use within the browser in 2023.
For those new to the Uno Platform, it allows for creating pixel-perfect, single-source C# and XAML apps that run natively on Windows, iOS, Android, macOS, Linux and Web via WebAssembly. In addition, it offers Figma integration for design-development handoff and a set of extensions to bootstrap your projects. Uno Platform is free, open-source (Apache 2.0), and available on GitHub.
2022 didn’t really feel like it had a lot of movement as far as features being released go but it did feel like there were a lot of things coming into place for what’s to come.
Things like tail calls and garbage collection will allow languages to shrink their module sizes and run faster. Additional languages might even be able to target WebAssembly as a result.
I believe the ability to use WebAssembly side-by-side with your existing containers, as well as share WebAssembly images in container repositories, is going to help the ecosystem grow even more outside the browser.
Finally, projects like compiling SpiderMonkey to WASI could see even faster JavaScript execution outside the browser and the possibility of more places where your JavaScript code can run.
To upgrade to the latest release of Uno Platform, please update your packages to 4.7 via your Visual Studio NuGet package manager! If you are new to Uno Platform, following our official getting started guide is the best way to get started. (5 min to complete) Or, to get started building powerful, fast, and reliable WebAssembly applications with Uno Platform, follow our Introduction to WebAssembly for .NET Developers Tutorial.
🕓 9 MIN In this article, I’m …
