The World Wide Web Consortium made WebAssembly Core an official Web standard on 5 December 2019, establishing a portable, low-level code format for computation in browsers and other environments. For teams considering it for a browser application, the important boundary is between running that code and connecting it to the Web. W3C says network and application-programming-interface access goes through accompanying JavaScript libraries; a separate, same-day Recommendation defines the JavaScript interface to WebAssembly. Standardization does not make those connections disappear. [S1][S2]

W3C presents WebAssembly as a compilation target for existing code bases, with uses including audio and video codecs, graphics and games. Its announcement describes near-native performance and faster loading as benefits. Those are W3C’s stated capabilities, not a measured speed-up for a particular application. The useful distinction for a product team is that moving a computational component into WebAssembly and replacing an entire application are different projects: the component still needs the surrounding interfaces its work depends on. [S1][S2]

The December 2019 JavaScript interface makes that dependency concrete. Its validate operation checks a module’s bytes, while creating an instance also involves reading the module’s imports from an object supplied by the host. If a module requires imports and that object is absent, the specification calls for a TypeError. If a function import is supplied with a value that cannot be called, it calls for a LinkError. A valid module therefore does not, by itself, establish that the application has supplied usable connections. [S2]

A size limit is not a resource promise, either. The JavaScript-interface Recommendation sets a maximum module size of 1 GiB, or 1,073,741,824 bytes, and requires rejection above its prescribed limits. It also explicitly warns that an implementation can run out of resources for valid modules below those limits. The practical reading is narrower than “a module this size will run”: conformance limits and the resources available in a deployment answer different questions. [S2]

The roadmap needs the same separation from the approved standard. In its December announcement, W3C lists threading and fixed-width vector operations, known as SIMD, among features being developed for future versions. It describes the WebAssembly System Interface, including file and network functionality, as a longer-term project. Those plans should not be counted as features delivered by the new Recommendation. For an adoption decision in December 2019, the dated interface and its host requirements are a firmer basis than the eventual scope of the roadmap. [S1][S2]

Source documents

  1. W3C: WebAssembly becomes a W3C Recommendationhttps://www.w3.org/press-releases/2019/wasm/
  2. WebAssembly JavaScript Interface — W3C Recommendation, 5 December 2019https://www.w3.org/TR/2019/REC-wasm-js-api-1-20191205/