WebAssembly 2021 Review and 2022 Outlook

Author | Uno platform team

Translated by | Xu Xuewen

Planning | Yan Garden

Review | Wang Qiang

This article was originally published on a blog on the Uno platform.

As with last year,last year when the authors wrote webAssembly 2020 development and 2021 forecasts, this article will review WebAssembly's development over the past year and then predict its trends for the coming year.

Review 2021

WebAssembly has evolved much faster over the past year than I had previously predicted, especially in safari web browsers.

Safari

When the MVP version of WebAssembly was first released in 2017, Safari was on the same level as other browsers. Then, after years of development, Safari was unfortunately left behind.

Fast forward to 2021 and I'm excited to see Safari continue to post updates to WebAssembly support. This may be the beginning of Safari's catch-up with other manufacturers. With the release of Safari 15.2 on December 14, 2021, the Full Year 2021 Safari Update releases the following features:

Stream compilation

Large memory operations

Addressable memory up to 4GB

Exception handling

Response headers that support COOP and COEP

Atomic instructions

Turn back on support for shared buffers for sites that use COOP/COEP response headers

Shared cache

With shared buffers, WebAssembly enables memory sharing between multiple threads. Unfortunately, due to the current Spectre and Meltdown vulnerabilities in shared caches, shared buffers are disabled until a suitable vulnerability solution is found.

The Chrome desktop app was the first to re-enable shared caches by employing site isolation as a vulnerability solution. After that, adding COOP or COEP to the response header means telling the browser that an isolated environment needs to be created to safely re-enable the shared buffer.

The Firefox desktop app re-enabled shared buffers in 2020 by adding these headers to response headers. By early 2021, the Chrome desktop app will update support for shared buffers to the latest standards. After that, if you want to use the shared buffer feature, you'll have to add these response headers.

At the same time, Chrome's Android side also announced support for these response headers in early 2021, making it possible to use WebAssembly's multithreading on mobile. With the latest version of Safari turning back on support for shared buffers, all modern browsers except Firefox mobile support multithreading for WebAssembly.

I expected Firefox mobile to support these response heads in 2021, but unfortunately that didn't happen. However, in 2022, Firefox mobile is very likely to complete support for these response heads.

Fixed-width SIMD

SIMD is the same instructions acting on multiple nodes of the data at the same time, which can greatly improve computing performance in this way. For example, by taking advantage of the CPU's SIMD instructions, you can greatly improve your image processing capabilities.

There are many types of SIMDs, and as a starting point, WebAssembly decided to support 128-bit fixed-width SIMD operations first.

Chrome and Firefox added support for fixed-width SIMDs in May and June 2021, respectively, although Safari does not currently support them.

Until now, WebAssembly did not have a built-in exception handling module, and to fill this gap, applications had to use JavaScript to add additional exception handling code. However, when the logic code for handling these exceptions is built inside the module, it will not only make the module larger but also affect the performance. Therefore, it is generally recommended that you do not use exception handling in modules that are not required.

Chrome officially released exception handling in September, but to my surprise, Safari also implemented exception handling in December and decided to release it officially in version 15.2.

Firefox and Node .js are not yet supported, and they are still working on development.

According to the release notes for V8 (The JavaScript engine for Chrome and Node .js), exception handling using WebAssembly has decreased by 43% compared to using JavaScript, an increase in code size by 9% compared to not using any exception handling. At the same time, WebAssembly's exception handling has no impact on performance, while JavaScript's exception handling has a 30% negative impact on performance.

If you are interested in the details of WebAssembly exception handling in the V8 release, you can check out the V8 release notes: https://v8.dev/blog/v8-release-95#webassembly.

Module link and interface type

A module link proposal is about establishing a link between two or more module definitions and having the WebAssembly runtime handle the link for you while it is running.

The interface type proposal describes how modules communicate with each other through advanced data type definitions. For example, if one module might use UTF-8 strings and another might use UTF-16 strings, it would be easier for the WebAssembly runtime to communicate between modules by describing their data types.

I had expected both proposals to be completed in 2021, but it seems that while some phased results have been achieved, there is still a need to continue to work in the future.

.NET 6

Over the past year, .NET has put a lot of effort into further improving support for WebAssembly, both in terms of tools and performance. The AOT compilation feature released in the November 6 release is one of them.

usually. The compilation of NET code is a two-step process, starting with the native code compiled into IL (an intermediate language in the .NET schema), and then compiling the rest on the target machine of the deployment through on-the-fly compilation of the target machine. The process is actually somewhat similar to how WebAssembly works.

When the code for this compilation mechanism is running in the client browser, the WebAssembly code is. The NET WebAssembly runtime itself, while the application's code is all IL files. This on-demand compilation and execution of IL files is not comparable in performance to the way compiled files are executed directly.

In the AOT compilation mode, the application's . The NET code will all be compiled into WebAssembly. This approach increases the file size but results in better performance, but large files can cause the app to take too long to load first.

Given the advantages and disadvantages of the two different compilation methods of IL and AOT, using configuration-oriented AOT compilation may be the best choice. In this way, we can compile frequently used code through AOT, while the rest is compiled in IL.

In addition to this, our Uno platform introduces a feature called XAML resource trimming. It can remove unused code along with AOT compilation. In testing, it was found that this way reduced the code of the WebAssembly application by 50%.

Bytecode federation

The Bytecode Alliance was originally an organization of Intel, Mozilla, Red Hat, and Fastly, with the goal of building a secure platform that could run untrusted code on any platform, device, or operating system by leveraging standards such as WebAssembly and WASI.

WASI (WebAssembly System Interface) is a standard for how webAssembly is used securely and consistently in scenarios outside the browser. If you want to learn more about it, Lin Clark wrote a great article to explain WASI: WASI-WebAssembly System Interface Standard: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/.

From the beginning, the alliance hopes that more organizations will join, so the internal structure of the organization must be adjusted accordingly to meet the future development and growth of the organization. At the time of the foundation, Red Hat withdrew, and Microsoft joined and helped other founders merge the organization into a nonprofit. In 2021, the alliance was expanded to include Microsoft, Google, Arm, the DFINITY Foundation, Plump Studios, Shopify, and the University of California, San Diego.

In addition to supporting WASI, the alliance is also a source for projects such as Wasmtime, Cranlift, Lucet, WAMR, and Enarx. If you're interested in the Bytecode Consortium, you can get more information via the link: https://bytecodealliance.org/.

WebAssembly application areas

Every year we see more and more commercial products add support for WebAssembly. In 2020, for example, Zoom, Google Meet, Google Earth, and Firefox browsers are all joining the race for WebAssembly-based non-service computing products such as Cloudflare Workers. In addition, there is eBay's barcode scanner, AutoCAD's web application, and the Unity game engine.

2021 is no exception, and here are some of the new areas where WebAssembly is being leveraged:

The Disney+ Application Development Kit uses WebAssembly

A simplified version of Photoshop was published on the web page

Microsoft's Flight Simulator has a webassembly-based plugin system

With improvements in functionality and tools, and more and more commercial products using WebAssembly, we're starting to see WebAssembly applied to both frameworks and the general web. Although there are still few application areas and products, his continued growth is exciting.

2021 is a great year for WebAssembly, so what do we expect from 2022?

Forecast 2022

I think what's bound to happen in 2022 is that WebAssembly's capabilities in almost all areas will be further enhanced and improved. What I'm most looking forward to is exception handling.

Exception handling is a major feature necessary for many programming languages, so it sits at the top of the to-do list. Safari, Chrome, and Edge already have this feature, and Firefox and Node .js are under active development.

Since the low-performance version of JavaScript can still be used, when you need to use exception handling in your module, if you can use better performance WebAssembly exception handling, then upgrade to use it, otherwise fall back to the version that uses JavaScript exception handling.

As mentioned earlier, almost all modern desktop and mobile browsers, including the Firefox desktop, now support COOP/COEP response headers. These response headers allow the browser to safely enable shared buffers, allowing your module to multithread using WebAssembly.

In modern browsers, only Firefox mobile does not support these response headers, but Firefox mobile has planned to support them in version 97 released in February 2022.

I predict that this feature will be implemented in this year's version of Safari.

My reasoning is that Safari added support for WebAssembly in 2021, the WebAssembly fixed-width SIMD specification is now standardized, and Xcode (Apple's operating system development environment) already supports SIMD.

Tail call

In order to support WebAssembly, some programming languages have to use tail calls, and although many things can have a workaround path, the process is slow. In addition, tail calls also play a positive role in compilation optimization and process control. The proposal has been around for some time, but to move on to the fourth phase, at least 2 vendors (Chrome, Firefox, or Safari) will have to implement this feature. Chrome has implemented this feature in a version tab, but Chrome doesn't intend to release it officially until it reaches its fourth stage. So we still have to wait for at least one more vendor to implement this feature.

It's not that vendors don't want to implement this feature, it's that they're all busy with what they think is more important. So people are trying to increase the importance and priority of this feature in the eyes of various vendors.

Support for multiple memory

The proposal is to make a module have multiple memory modules.

One use case for multiple memory is when a module uses one memory region as its own internal data region and passes another memory region to some module that needs to write data. In this way, you can prevent errors in the data inside the module from occurring due to abnormal writes from the external module. At the same time, this method can also isolate sensitive data and share data well, which plays a certain security role.

Another use case for multi-memory is that in webAssembly's multithreading, you can have these threads have a shared memory region while saving other module data to another memory region.

If you are interested in the use of multiple memory areas, you can check out the Introduction to Multiple Memory (https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md) to learn more about the usage scenarios.

At present, this proposal has reached the third stage, and there are many compelling application scenarios. So I especially hope that it will be officially released this year.

WASI (WebAssembly System Interface)

As mentioned earlier in this article, I expect both module linking and interface types proposals to be completed in 2021. Unfortunately, they are still in progress and are not completed in 2021 as I expected.

These recommendations are not just part of WebAssembly, they are essential features for creating component models. According to this WASI help documentation, the component model is similar to the operating system's process model and is used to define how processes start and communicate with each other. WASI plays a role here similar to the API layer of an operating system.

As a result, both the component model and WASI's interface type proposals for 2022 will continue to evolve. If you are interested in WASI proposals, you can see more through the WASI Proposals List (https://github.com/WebAssembly/WASI/blob/main/docs/Proposals.md).

Summary

Over the past year, we've seen features like WebAssembly multithreaded shared buffers, fixed-width SIMDs, and exception handling in terms of improving WebAssembly performance. meantime. Support for WebAssembly has been improved in NET6, and . Both the NET and Uno platforms further improve the performance of WebAssembly by adding AOT.

Safari is a big surprise in 2021, and they're doing a lot of work to catch up with WebAssembly support for other browsers.

In 2021, we'll see more commercial products joining the ranks of using WebAssembly, and WebAssembly is starting to be used on the mass web.

In this way, 2022 will be another good year for WebAssembly, because those features that are not supported today are likely to be officially released and put into production in 2022.

There are many interesting feature proposals for WebAssembly itself, and the Bytecode Alliance will continue to help WebAssembly land and upgrade its functions in the browser's scenarios.

If you're interested in the evolution of WebAssembly feature support, you can learn more about it through the following web site. The first column shows a list of features: WebAssembly Feature RoadMap (https://webassembly.org/roadmap/).

Thanks to guest guest Gerard Gallant, author of the book "WebAssembly in Action" and a senior software developer, he wrote another comprehensive article on the current and future state of WebAssembly.

Original address:

https://platform.uno/blog/the-state-of-webassembly-2021-and-2022/