Google, Microsoft, Mozilla, and others have teamed up to launch WebAssembly, a new binary format for the Web.
Google , Microsoft , Mozilla, and the WebKit project engineers on June 17 announced that they had teamed up to launch WebAssembly , a new binary format for compiling web applications.
The web is evolving thanks to standards, and, badly or well, JavaScript is one of them. However, over the years we have seen many attempts to circumvent the limitations of a language, for example, creating compilers that translate code from other languages into JavaScript. Some of these projects focus on adding new features to the language (for example, Microsoft's TypeScript ) or speeding up JavaScript (for example, Mozilla asm.js ). Now many of these projects are combined in one form or another in WebAssembly.
The new format allows programmers to compile their code for the browser (currently, developers have focused on C / C ++, other languages will be added later). This compiled code is subsequently executed inside the JavaScript engine. Instead of parsing the source code, which still often takes a long time (especially on mobile devices), WebAssembly can be decoded much faster.
The idea is that WebAssembly will provide developers with a single way to compile, which will eventually become the web standard implemented in all browsers.
')
JavaScript files are simple text files that are downloaded from the server and then parsed and compiled by the JavaScript engine in the browser. The WebAssembly team decided to use the binary format because the code can be compressed better than the standard JavaScript text file, and because it is much faster for the engine to decode the binary format (up to 23 times faster in the current implementation) than, for example, to decode asm.js code.
The asm.js project from Mozilla has a long-term goal to bring speeds that are close to native speeds on the web. Google's Native Client project for running native code in a browser has a similar goal, but has received relatively little distribution. It seems that now WebAssembly has the ability to bring the best from these projects to browsers.
As a first step, the WebAssembly team aims to achieve the same functionality as asm.js (and developers will be able to use the same Emscripten utility for WebAssembly that they use to compile asm.js code now).
At this early stage, the team also plans to launch the polyfill library , which will translate the WebAssembly code in JavaScript in such a way that it can be executed by any browser - even without the built-in support for WebAssembly (which is obviously absurd, because there will be no need for this library as soon as browsers get native support for WebAssembly). Over time, the team will develop more utilities (compilers, debuggers, and others) and add support for other languages (for example, Rust, Go, and C #).
The team draws attention to the fact that the meaning of their ideas is not to replace JavaScript, but to add the ability to compile a large number of other languages for the web. Indeed, the chances are that both JavaScript and WebAssembly will be used together, side by side. For example, part of an application can use WebAssembly modules (animation, visualization, compression, etc.), and the user interface will be mainly written in JavaScript.
We rarely can see that all significant browser developers are working together on such a project, so something definitely worthwhile awaits us ahead.
The web is evolving thanks to standards, and, badly or well, JavaScript is one of them. However, over the years we have seen many attempts to circumvent the limitations of a language, for example, creating compilers that translate code from other languages into JavaScript. Some of these projects focus on adding new features to the language (for example, Microsoft's TypeScript ) or speeding up JavaScript (for example, Mozilla asm.js ). Now many of these projects are combined in one form or another in WebAssembly.
The new format allows programmers to compile their code for the browser (currently, developers have focused on C / C ++, other languages will be added later). This compiled code is subsequently executed inside the JavaScript engine. Instead of parsing the source code, which still often takes a long time (especially on mobile devices), WebAssembly can be decoded much faster.
The idea is that WebAssembly will provide developers with a single way to compile, which will eventually become the web standard implemented in all browsers.
')
JavaScript files are simple text files that are downloaded from the server and then parsed and compiled by the JavaScript engine in the browser. The WebAssembly team decided to use the binary format because the code can be compressed better than the standard JavaScript text file, and because it is much faster for the engine to decode the binary format (up to 23 times faster in the current implementation) than, for example, to decode asm.js code.
The asm.js project from Mozilla has a long-term goal to bring speeds that are close to native speeds on the web. Google's Native Client project for running native code in a browser has a similar goal, but has received relatively little distribution. It seems that now WebAssembly has the ability to bring the best from these projects to browsers.
As a first step, the WebAssembly team aims to achieve the same functionality as asm.js (and developers will be able to use the same Emscripten utility for WebAssembly that they use to compile asm.js code now).
At this early stage, the team also plans to launch the polyfill library , which will translate the WebAssembly code in JavaScript in such a way that it can be executed by any browser - even without the built-in support for WebAssembly (which is obviously absurd, because there will be no need for this library as soon as browsers get native support for WebAssembly). Over time, the team will develop more utilities (compilers, debuggers, and others) and add support for other languages (for example, Rust, Go, and C #).
The team draws attention to the fact that the meaning of their ideas is not to replace JavaScript, but to add the ability to compile a large number of other languages for the web. Indeed, the chances are that both JavaScript and WebAssembly will be used together, side by side. For example, part of an application can use WebAssembly modules (animation, visualization, compression, etc.), and the user interface will be mainly written in JavaScript.
We rarely can see that all significant browser developers are working together on such a project, so something definitely worthwhile awaits us ahead.
Source: https://habr.com/ru/post/260667/
All Articles