Engineers from Google and the other major browser makers, including Apple, Microsoft and Mozilla, are working on a new standard dubbed WebAssembly (wasm) for running compiled code in Web browsers.
When complete, WebAssembly will be a new machine-readable instruction set, or bytecode, that will let non-JavaScript source code run more efficiently in modern browsers.
WebAssembly will run on JavaScript engines and will provide a secure format for running compiled C and C++ code (and eventually other languages) in browsers, according to descriptions of the effort by the browser makers. The idea is to enable Web applications written in different programming languages to run at near native speed in any browser.
The kind of bytecode being considered under the effort can be natively decoded about 20 times faster than JavaScript can be parsed, according to a FAQ on the project posted on GitHub. The new standard makes it significantly easier to add features that will let browsers run Web apps at near native levels of performance, it said.
Applications such as remote desktop; VPN; encryption; image and video editing; peer-to-peer applications including games, music streaming and caching; image recognition; and more will benefit from WebAssembly, the FAQ said.
“A central requirement for WebAssembly is that it integrate well with the rest of the Web platform and that the initial version run efficiently on current browsers,” using appropriate client-side plug-ins, Mozilla engineer Like Wagner said in a blog.
However, WebAssembly will not replace JavaScript, the FAQ emphasized. Instead, WebAssembly will be a complement to JavaScript and will over time allow multiple languages to be compiled to the Web. But JavaScript will remain the “single, privileged dynamic language of the Web,” the FAQ said. In fact, JavaScript and WebAssembly will be used together in a number of situations, it added.
All stakeholders involved in the project have a clear idea of the long-term goals. But the process itself is still very much in the early stages, Wagner said. “There is no draft spec or even [a] final formal standards body” selection, he said.
All that has been established so far is a community working group, some early prototyping and some early consensus on high-level design documents. “Going forward, there will be a lot more iteration and experimentation under the WebAssembly GitHub organization,” he said.
WebAssembly will make compiling to the Web even faster than possible with the current asm.js subset of JavaScript, said Microsoft software engineer Mike Holman. The browser makers have come to an agreement on a shared set of goals, Holman said. From Microsoft’s standpoint, what it wants from WebAssembly is full interoperability with JavaScript.
“The Web already has a vibrant ecosystem and anything we add should interface nicely with it,” Holman said. Also critical is broad language support and high, native-level performance. “Right now we are working under the WebAssembly W3 Community Group and experimental/design ideas are being discussed on GitHub.”
WebAssembly will introduce new maintenance costs as well as issues pertaining to security and code size, the FAQ conceded. But the effort is to minimize disruption by having a design that allows a browser to implement WebAssembly inside the current JavaScript engine. “Thus, in cost, WebAssembly should be comparable to a big new JS feature, not a fundamental extension to the browser model,” it said.
