Author | Jin Lingjie
WebAssembly has been a hot topic on the front end since the release of the WebAssembly standard and the completion of default support by major browsers. Prior to WebAssembly, similar front-end binary standards were firefox led asM.js and Chrome led PNaCl. Both use back-end C/C++ code for the front end, and as a compromise, the WebAssembly standard favors asM.js implementations. Chrome has announced that it will drop support for PNaCl after supporting the WebAssembly standard.
As a front-end standard, PNaCl has its inherent deficiencies at the beginning of its establishment. In terms of design, the PNaCl code is highly independent from the front-end code (JavaScript, HTML, etc.), and the PNaCl code runs in an independent process, which makes the cost of interaction between the PNaCl code and the page code very high (IPC is required). In addition, for security reasons, PNaCl processes run in a sandbox environment, so Chrome defines an API called Pepper for this purpose. Many of the apis defined by Pepper overlap with current Web standards.
A more serious problem is that neither Pepper nor PNaCl has a clear binary code specification. So for non-Chrome browsers to be compatible with the PNaCl plug-in, either reverse engineer Pepper to implement its own interface implementation or import the implementation code from the Chromium project. Either way, you need to synchronize with Google’s changes. This is unacceptable for developers.
In contrast, the ASM.js implementation is as close to front-end development and existing front-end standards as possible from the outset. Asm.js represents memory with a Javascript array and compiles C/C++ code to Javascript to manipulate this array. This implementation has a big advantage over PNaCl: all the codes run in the same JS virtual machine and can easily interact with other JavaScript codes and DOM. In addition, this implementation introduces no new apis, so there is less document-related work.
To sum up, the WebAssembly standard is ultimately closer to asM.js, which is implemented in a JS virtual machine and can be easily invoked between pages of JavaScript. The WebAssembly standard does not define new platform-specific apis, other than those related to loading and linking WebAssembly code. Unlike ASM.js, WebAssembly fully defines the binary code specification, which is already documented.
Of course, Google and other groups have contributed to the development of the WebAssembly standard. For the PNaCl plug-in, Google has published migration documentation. The real winners from the release of WebAssembly standards are the developers!
Today’s recommendation,
Click on the image below to read it
Sofish in-depth interview: help you understand the growth of front-end engineers and large front-end teams!
Recommend a conference that front-end people should not miss: The Global Architect Summit, which invited hundreds of top technical experts at home and abroad to share the core architecture design of various businesses, from the bottom optimization of Web protocol to the series of magic changes of super App, here only talk about the best architecture practice.
The conference will open on July 7th in Shenzhen, with 10% off for the last week. Click “Read the original article” to get 100+ landing cases, and see what inspires you?
InfoQ is a vertical community focused on front-end technology. To join the InfoQ learning group, please follow the “Front-end top” public account and reply to “Add group”. To share or contribute, please send an email to [email protected], marked “Contribute to the top of the front”.
