🕓 12 MINWelcome to 2024 …
Welcome to our annual State of WebAssembly (wasm) article. In this article, I’ll start off with a review of what happened around WebAssembly in 2024 and then look at what I think might happen in 2025.
Table of Contents
Before I jump in though, I’d like to highlight a couple of points to make this article easier to follow.
When I talk about browser support for different WebAssembly features, I typically only mention Chrome, Firefox, and Safari. I don’t mention Edge or Opera because they’re built using the same Chromium open-source project as Chrome. It’s still a good idea to test your modules in these browsers but, because they’re built using Chromium, they usually inherit the work done around WebAssembly.
If you want to be sure that your browser does support a WebAssembly feature, you can use the following website. If your browser supports the feature, there will be a checkmark in the ‘Your browser’ column to the right of the feature’s name. The nice thing about this web page is that it also lists WebAssembly support in non-browser environments and runtimes.
The following website is also useful because it allows you to look up the status of various browser features ranging from HTML tags and CSS properties to Web APIs and WebAssembly features. This website does not indicate browser support if a feature is still behind a flag:
As you read this article, you’ll notice that I sometimes mention that a feature is ‘behind a flag’. When I say that, I’m referring to options that can be turned on or off by a user. In a browser, this is typically something that’s done by developers to allow testing of new features that aren’t quite ready for general use. Be very careful if you adjust the flags because they can change how the browser handles certain things. In some cases, because the feature may not be complete, there may be security issues with the implementation that haven’t been addressed yet.
Let’s dig in.
2024 in review
Safari
For the past few years, Safari has been putting in a lot of effort to enhance its WebAssembly support and 2024 was no exception. The following features were implemented in Safari this past year rounding out browser support for them.
Extended Constant Expressions arrived in Safari 17.4.
Extended Constant Expressions is a feature that’s more of a tooling item rather than something the average developer will leverage directly. This proposal is meant to help with dynamic linking of modules by adding additional instructions that can be used when initializing globals and specifying table or data offsets that aren’t known until runtime.
Typed Function References arrived in Safari 18.0.
Typed Function References allow for functions to be called directly without needing to be stored in the table section of a module. This allows function pointers to be passed between the module and host more efficiently.
Garbage Collection arrived in Safari 18.2.
Garbage Collection is needed by a number of managed languages to automatically release memory that isn’t needed anymore. Because, up until this specification, WebAssembly didn’t have garbage collection, languages that needed it had to either include their own garbage collector with the module or compile their runtime to WebAssembly. Both approaches result in bigger download sizes and a slower startup time especially if things aren’t cached yet.
Tail Calls also arrived in Safari 18.2.
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.
Also in 2024, the Relaxed SIMD feature became available behind a flag in Safari. At the moment, this feature is still behind a flag in Firefox as well and is only live in Chrome.
SIMD stands for Single Instruction, Multiple Data. SIMD is a type of parallel processing that takes advantage of a CPU’s SIMD instructions to perform the same operation on multiple points of data simultaneously. This can result in large 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.
When SIMD was proposed for WebAssembly, 128-bit fixed-width SIMD was chosen as a starting point because it was seen as having the most hardware support. There are additional SIMD instructions that are possible, depending on the hardware, so the Relaxed SIMD proposal’s aim is to take advantage of some of those additional instructions. If you’d like to learn more about Relaxed SIMD, the proposal can be found here.
There are additional features that I would like to see implemented in Safari but getting Garbage Collection was a very important milestone so I’m happy with the items they delivered in 2024.
Standardized Features
For a WebAssembly feature to become a standard, there are several requirements that need to be met including having at least two web VMs (Chrome, Firefox, Safari), and at least one toolchain, implement the feature.
Over this past year, the following features have reached phase 5 (standardized) and are now considered complete:
- Extended Constant Expressions
- Typed Function References
- Garbage Collection
- Tail Call
- Relaxed SIMD
- Multiple Memories
- With only a single block of memory, if a module needs to communicate with JavaScript, or another module by sharing its memory, it risks information being disclosed or accidentally corrupted. With this proposal, a module can now have multiple memory blocks. That opens possibilities like a module being able to keep one block for internal data while exposing another for the sharing of information for example.
- During 2024, this came out from behind a flag in Firefox leaving only Safari without an implementation.
- With only a single block of memory, if a module needs to communicate with JavaScript, or another module by sharing its memory, it risks information being disclosed or accidentally corrupted. With this proposal, a module can now have multiple memory blocks. That opens possibilities like a module being able to keep one block for internal data while exposing another for the sharing of information for example.
- Custom Annotations
- WebAssembly modules can contain custom sections for data that don’t apply to the standard (known) sections. Because custom sections are optional and can contain any data a developer or toolchain may want to include, there was no equivalent text format defined. This proposal aims to extend the text format so a custom section can also be defined in the text format.
- WebAssembly modules can contain custom sections for data that don’t apply to the standard (known) sections. Because custom sections are optional and can contain any data a developer or toolchain may want to include, there was no equivalent text format defined. This proposal aims to extend the text format so a custom section can also be defined in the text format.
- Branch Hinting
- This proposal’s aim is to help improve performance of modules by giving engines hints about which paths are most likely to be executed.
Newly Available Features
Exception Handling
There is already an Exception Handling proposal that’s live in all browsers. This proposal has been adjusted to include a new ‘exnref’ value to address a number of issues with the existing approach that includes difficulty for the JavaScript API to handle the identity of thrown exceptions. The exnref value also allows for a reduction in the complexity of both the specification and engine implementations.
Because exception handling is already live in all browsers, the original approach will continue to work until it’s determined that it’s safe to be removed.
This new approach is already live in Firefox but is behind a flag in all other browsers for the moment.
JavaScript String Builtins
The JS String Builtin feature is actually a first step to a larger goal of allowing the use of JavaScript builtin objects and primitives from a WebAssembly module without the need for JavaScript glue code.
Glue code is simply JavaScript code written by a developer, provided by a framework, or generated by a compiler toolchain to act as a middleman when the module’s code can’t do something independently. When the JavaScript code is called, it does some work on the module’s behalf.
The string object is the first builtin object that will be supported. You can find more information about this proposal here.
This feature is live in Chrome and Firefox but not yet available in Safari.
Memory64
The linear memory of a WebAssembly module was originally limited to a maximum of 4 GB because of the use of 32-bit indexes. Because some applications need more than 4 GB of memory, 64-bit indexes have been added.
There are some proposals in the works that may help improve things but, at the moment, there are a couple things to be aware of with this feature before you jump in:
- Even though a 64-bit pointer can theoretically access up to 16 exabytes of memory, in the browser, the WebAssembly JavaScript API limits memory to a maximum of 16 GB.
- Browser engines were able to make some optimizations around 32-bit pointers that they’re not currently able to do with 64-bit pointers. Without those optimizations, unfortunately, there is a potentially large performance hit depending on the workload. The following article goes into detail about why there’s currently a performance penalty when using 64-bit mode.
For now, the recommendation is that you should only use Memory64 if you need more than 4 GB of memory.
This feature is available in Chrome and Firefox but not yet in Safari.
Outside the Browser
WebAssembly System Interface (WASI)
WASI is a standardization effort led by the Bytecode Alliance for WebAssembly’s use outside the browser to ensure things are done in a secure and consistent way. It also includes the creation of a set of interfaces that your modules can access called worlds. For example, there’s a ‘wasi-http’ set of interfaces that your module can use to send and receive HTTP requests.
The WASI work is being released in phases and advanced to Preview 2 early in 2024. Preview 2 included the following features:
- Component Model
- The Component Model gives you a way to describe your module that allows for several WebAssembly modules, potentially written in different programming languages, to be linked together. If you’d like to learn more about the Component Model and how it works, the following website gives a detailed explanation.
- The Component Model gives you a way to describe your module that allows for several WebAssembly modules, potentially written in different programming languages, to be linked together. If you’d like to learn more about the Component Model and how it works, the following website gives a detailed explanation.
- wasi-cli world is a set of interfaces that allow your module to access command-line features like command-line arguments and environment variables.
- wasi-http world is a set of interfaces that allows your module to send and receive HTTP requests.
The Bytecode Alliance decided to change to dot releases instead of referring to the releases as previews. Now “Preview 2” is referred to as WASI 0.2. The next release will be WASI 0.3, formerly ‘Preview 3’ and then the WASI 1.0 release will be when WASI is standardized.
Following along with the dot versioning, the Bytecode Alliance started a patch release cadence every other month. At the same time, a number of additional worlds are now available as part of WASI 0.2.x including:
- wasi-io contains interfaces for working with different kinds of host streams.
- wasi-random provides a means of obtaining pseudo-random data for use in areas like cryptography.
- wasi-clocks contains interfaces for reading the current time and measuring elapsed time.
- wasi-sockets brings the ability to work with TCP/UDP sockets
- wasi-filesystem contains a set of interfaces for opening, reading, and writing files as well as working with directories.
The following GitHub page lists the WASI releases and what’s included in each.
.NET
Late in 2023, .NET added experimental support for WASI, but it’s still considered experimental and not officially supported. In 2024, the Bytecode Alliance released a NuGet package called ‘componentize-dotnet’ that gives C# developers an alternative approach to generate a WASI Component for their code. If you’d like to learn more, the following article gives step-by-step instructions on how to configure your application and use the NuGet package.
The Uno Platform team is constantly innovating and making improvements. This past year, as part of the Uno Platform 5.5 release, the team switched to the .NET 9 runtime rather than using their own .NET WebAssembly runtime. This has resulted in a streamlined WebAssembly process with fewer dependencies, faster build times, improved debugging, and will make migrating to new .NET versions easier. With this change, download and startup speeds are improved because size improvements are also seen ranging from 7% to 56% depending on the compilation mode chosen.
Also with the 5.5 release, Uno Platform became the first XAML framework to offer WebView2 in WebAssembly. This allows external or local web content to be displayed within your application while maintaining security through an iframe implementation. For more information about WebView2 support, and other Uno Platform 5.5 changes, feel free to read the following article.
Hyperlight
In last year’s WebAssembly review, I mentioned that Microsoft had given a teaser of something they were working on called Hyperlight. Hyperlight allowed Hypervisor to run micro virtual machines containing WebAssembly modules.
Microsoft has decided to open-source this project and hand it off to the Cloud Native Computing Foundation (CNCF) to help advance cloud-native technologies. The following article goes into more detail including information on how to use it from Rust.
Adoption
In the browser, tooling is starting to appear with features that ‘just work’ without a developer needing to jump through hoops to set up. For example, sql.js (SQLite), PGLite (Postgres), and DuckDB allow for local databases that accept familiar SQL queries as opposed to learning a new approach to use the browser’s IndexedDB. As things continue to progress, I think a lot of developers will be using WebAssembly in some area of their tech stack and may not even realize it.
WebAssembly’s use continues to grow in the browser. Based on the Chrome Platform Status metrics (click the ‘Show all historical data’ checkbox), the number of websites using wasm, visited by Chrome users, has increased by a little over 1% again this past year to now sit at close to 4.5%.
Every year, we hear about different commercial applications adopting WebAssembly. From video conferencing software like Zoom and Google Meet, software like Figma and AutoCAD web, and social media applications like Snapchat and Pinterest. Even Visa is using it to improve its payment processing systems.
In recent news, American Express has decided to use wasm for their internal Function as a Service (FaaS) platform. According to the following article, this could be the largest large-scale adoption of WebAssembly in a commercial application to date.
That doesn’t even scratch the surface of who’s using WebAssembly commercially. Increasingly, corporations are also leveraging edge computing and incorporating wasm into their cloud-native strategies. Millions of devices are also being shipped with wasm running on them.
For a while, there was a lot of hype and interest around WebAssembly. It was new and shiny with lots of potential but, at the same time, there were still some important features needed. Many features have now been added, and more are on the way, but it has also been 8 years since the MVP, so the hype has died down some.
The following NIST (National Institute of Standards and Technology) paper could cause a renewed interest in WebAssembly because of the influence this organization has. Their paper details how WebAssembly could be used to help improve data protection in cloud-native applications, but this could also spur renewed interest in how WebAssembly can improve security in general.
Expectations for 2025
Features likely available in all browsers this year
I believe the following features are close to becoming available and could be live in all browsers before the end of 2025:
- Type Reflection is available behind a flag in all browsers. The proposal is still in phase 3 (implementation) of the specification process but, based on some meeting notes at the end of 2023, they were expecting to vote to move this to phase 4 (being standardized) at a later meeting. I could see this advancing this year. Once it moves to phase 4, browsers can bring the feature out from behind a flag.
- This proposal is to modify the WebAssembly JavaScript API so that it’s possible to query information about the data types of functions imported and exported from a module.
- Relaxed SIMD is now in phase 5, so I expect it will come out from behind a flag in Firefox and Safari this year.
- Exception handling with exnref is in phase 4 and behind a flag in all browsers except Firefox where the proposal is live. I expect that all browsers will move this feature out from behind a flag this year.
Safari
A lot of work has happened over the past few years to add WebAssembly features to Safari and I have no reason to think that will change this year. Now that they’ve finished implementing the Garbage Collection proposal, I suspect that we’ll see them tackle the following features this year:
- Multiple memory is at phase 5 and is live in all other browsers. A ticket for implementing this feature is already assigned.
- Memory64 is at phase 4 and is going live in the other browsers in January.
- JS String builtins is at phase 4 and is live in Chrome. It’s still behind a flag in Firefox but, given Firefox championed this proposal, I suspect it will come out from behind a flag in that browser shortly.
Other features that are possible this year
JavaScript Promise Integration
This feature’s aim is to allow a wasm module to continue to be built with synchronous function calls 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.
This proposal is still in the implementation phase and behind a flag in all browsers except for Safari. At the moment, I’m not sure where this stands for Safari.
ESM Integration
ESM stands for ECMAScript Modules and is a standard format for the packaging of JavaScript code for reuse.
Up until this point, to call a function in a WebAssembly module, you need to fetch the .wasm file and then instantiate it manually as shown in the following example.
const req = fetch(“./myMath.wasm”);
WebAssembly
.instantiateStreaming(req, { …imports… })
.then(res => {
console.log(res.instance.exports.add(1, 3)); // Prints 4 to the browser’s console
});
With the ESM Integration proposal, the idea is that you can just use the import keyword and the host would handle all of the downloading and instantiation for you. This is referred to as evaluation phase imports. For example:
import { add } from ‘./myMath.wasm’
console.log(add(1,3)); // Prints 4 to the browser’s console
Based on what I’m hearing, the first step towards supporting this ability will be source phase imports. For example:
import source mathModule from “./myMath.wasm”;
const myInstance = await WebAssembly.instantiate(mathModule, { …imports… });
console.log(myInstance.add(1, 3)); // Prints 4 to the browser’s console
Once source phase imports are complete, the second step will be to implement evaluation phase imports as well.
.NET
With the WebAssembly Garbage Collection proposal now available in all browsers, one would hope that would mean that the .NET runtime would be able to take advantage of it. Unfortunately, when the .NET team was looking at the proposal in 2023, they indicated that it wasn’t possible for .NET to use it. They were, however, looking into the possibility of contributing to the post-MVP plans for Garbage Collection. Now that the MVP of Garbage Collection is standardized, hopefully work can happen to allow .NET to take advantage of the browser’s garbage collector too.
Another WebAssembly feature that would be nice to see is threading. Based on a recent Community Standup planning discussion for .NET 10, they indicated that multithreading is probably not going to make the cut. The discussion can be found here.
WebAssembly System Interface (WASI)
WASI 0.3 (formerly called Preview 3) is expected in the first half of 2025. The goal with this release is to include native async with the Component Model and then to adjust the existing WASI 0.2 interfaces to take advantage of the new async capabilities. If you’d like to learn more, the following YouTube video gives a deeper dive on how async will work in the Component Model in WASI 0.3.
In Conclusion
Every year we see many WebAssembly-related improvements and 2024 was no exception. This past year several important features, like Tail Calls and Garbage Collection, became available in Safari rounding out support in all major browsers. We should start seeing more WebAssembly implementations by programming languages that were waiting for cross-browser support.
In the browser, there are a number of features in the works, like JS Promise Integration and ESM Integration, that will make wasm feel more first-class and easier to work with for all developers. As time goes on, web developers may not even realize they’re making use of WebAssembly. They’ll just include the desired feature in their package manager, import the desired binding from the module, and work with it the same as do for any other JavaScript object.
From the .NET side of things, Uno Platform has continued to innovate and make improvements. With the Uno Platform 5.5 release and the switch from their own runtime to the .NET 9 runtime, there have been size, performance, and debugging improvements. They also became the first XAML framework to support WebView2 in WebAssembly to allow secure external content in your web application.
Outside the browser, we’re seeing exceptional growth for WebAssembly thanks to the work happening with WASI, the runtimes, and in the community. This past year, WASI 0.2 (formerly called ‘Preview 2’) was released bringing the Component Model as well as two worlds: wasi-cli and wasi-http. Since then, additional worlds have been included as part of the 0.2 patch releases. With the async capabilities that are coming as part of the WASI 0.3 release that’s expected later this year, the possible uses for wasm outside the browser continues to grow.
Because of all the exciting features being worked on in both WebAssembly and WASI, it’s easy to get caught up waiting for the next amazing thing. The reality is, however, that wasm and WASI already have a tremendous amount of capabilities that we can start using right now. WebAssembly’s use in commercial applications is constantly growing and, as we saw with the NIST report, there is huge potential for it around helping with data protection and security in general.
Next Steps
Start building your first Uno Platform app now and see how quickly you can deploy across platforms. Our templates and tooling get you productive from day one.
Tags: WASM, WebAssembly, wasi
- WASI, WASM, Web, WebAssembly
Related Posts
🕓 8 MINShare on twitter …
🕓 9 MINIn this article, …
