WebAssembly: The Definitive Guide

Chapter 12. Extending the WebAssembly Platform

He picks up scraps of information He’s adept at adaptation ’Cause for strangers and arrangers Constant change is here to stay

Rush, “Digital Man”

The MVP definition of WebAssembly put a stake in the ground but was never intended as a comprehensive solution for all uses. It primarily focused on language features that are ubiquitous and runtimes that do not require the complexities of threading, garbage collection, and exception handling. There were several other limitations that we have seen throughout the book. While it is impressive that people have found ways around these shortcomings, the MVP was never the end state. It was the beginning.

The designers of the WebAssembly platform have taken a surgical approach to its decisions. While it may be confusing from the outside, there is an internal consistency that takes into consideration several of the larger and longer-term goals. Many of the motivations for these decisions are documented alongside the specifications themselves. Rather than lumping shoehorned solutions to the omissions into the next big release, the designers have created a series of follow-on proposals that are tracked independently. Several of these proposals are interdependent, so there is an order to which they have been submitted and adopted.

Because the post-MVP world is evolving this way, it gets a little tricky to keep track of which features are available in which distribution. I fully expect there to ...