Last month we shared here on the blog about the news that Mozilla, Fastly, Intel, and Red Hat had teamed up to develop the technologies that make WebAssembly (If you want to know more about the news, you can consult it this link) and now few weeks after that news The W3C Consortium has announced that the technology WebAssembly it has become the recommended standard.
For those unfamiliar with WebAssembly they should know that this provides a middleware universal browser-independent low-level to run applications compiled from various programming languages. WebAssembly is positioned as the most promising and portable cross-browser technology for building high-performance web applications.
Web Assembly se can be used to solve tasks that require high performance, for example, video encoding, sound processing, 3D graphics and manipulation, game development, cryptographic operations, mathematical calculations, and the creation of portable implementations of programming languages.
WebAssembly looks a lot like Asm.js, but differs in that it is a binary format that is not bound to JavaScript. WebAssembly does not require the use of a garbage collector, since explicit memory management is used.
A distinctive feature of the execution model of applications that use WASI is launching in a sandbox environment to isolate from the main system and the use of a security mechanism based on capacity management, for actions with each of the resources (files, directories, sockets, system calls, etc.)
By enabling JIT for WebAssembly, you can achieve performance levels close to native code. Among the main tasks of WebAssembly is the provision of portability, predictability of behavior and identity of code execution on different platforms.
Recently, WebAssembly is also advancing as a universal platform to run code safely on any infrastructure, operating system and device, not limited to browsers.
W3C has standardized three specifications related to WebAssembly:
- Web Assembly Core- Defined as a low-level virtual machine that closely mimics the functionality of many microprocessors it runs on. Either through compilation or Just-In-Time interpretation, the WebAssembly engine can run at nearly the speed of compiled code for a native platform.
A resource .wasm is analogous to a file .class of Java in the sense that it contains static data and code segments that operate on that static data. Unlike Java, WebAssembly is generally produced as a compilation target for other programming languages such as C / C ++ and Rust. - WebAssembly Web API: defines a programming interface based on the Promise mechanism for requesting and executing ".wasm" resources. The WebAssembly resource format is optimized to start execution without waiting for the file to fully load, improving the responsiveness of web applications.
- WebAssembly JavaScript interface: provides an API to integrate with JavaScript. Allows you to get values and pass parameters to WebAssembly functions. Execution of WebAssembly corresponds to the JavaScript security model, and all interaction with the host is carried out in a similar way to executing JavaScript code.
In the future, it is planned to prepare specifications for WebAssembly functions such as:
- Multithreading with shared memory and access to atomic memory.
- Vector operations based on SIMD, which allow to parallelize the execution of cycles.
- Reference types for direct references to objects in WebAssembly code.
- Ability to call functions without spending additional space on the stack.
- Integration with ECMAScript modules: the ability to load WebAssembly code from JavaScript as modules that comply with the ECMAScript 6 specification.
- The way of working with the garbage collector.
- Debugging interfaces.
- WASI (WebAssembly System Interface): API for direct interaction with the operating system (POSIX API to work with files, sockets, etc.).
If you want to know more about it, you can consult the original note In the following link.