Initial discussion of Webassembly

Before we start talking about Webassembly(hereafter referred to as WASM), let’s take a look at why wASM is a new Web format. It starts with the birth of Javascript.

The birth of Javascript

In 1994, when Netscape was founded, it released version 0.9 of Navigator, a browser that could only be used to browse, not interact with users. In 1995, Brendan Eich came to Netscape and worked on Mocha for 10 days. Mocha was later renamed LiveScript, and finally changed to Javascript as Netscape tried to capitalize on the popularity of Java.

Brendan Eich’s main focus was functional programming, and Netscape wanted to investigate the possibility of using the Scheme language as a web scripting language. Brendan Eich agrees. Netscape wanted the web scripting language to be similar to And simpler than Java and accessible to non-professional developers. However, Brendan Eich didn’t like Java at all, so he designed JavaScript in 10 days.

Disadvantages of Javascript and ways to improve it

Because JavaScript was originally intended for simple interaction in the browser, Brendan Eich did not consider JavaScript in some complex scenarios. With the development of the Internet, JS has become the most widely used programming language on the Web. As a result, JavaScript is left with a lot of pitfalls, such as no types, exceptions (later added), object model, etc. The biggest one is JavaScript performance.

JavaScript is an interpreted language and is single-threaded, so it is inefficient and slow to execute. At this time, Web applications are becoming more and more complex. For example, in some real-time application scenarios (such as commodity killing), JavaScript seems to be weak, so smart engineers will not ignore this problem. In 2009, Google introduced JIT(Just-in-time compilation) technology in Chrome. With this technology, JavaScript execution efficiency has been improved 20-40 times, resulting in the emergence of a number of large Web applications. With the further development of the Internet, JIT performance improvement cannot meet the increasingly complex Web applications. For example, if the data type of the same variable changes, the JIT will have to be pushed back to the original. Second, the JIT will not optimize the code. It will simply translate the code in a rude way. Third, the JIT fails to generate code in some cases, such as exceptions, for in, and so on. All in all, the performance gains from JIT are limited, probably because JavaScript itself is so slow to compile. Smart engineers are not easily stumped by such problems, and they are constantly exploring and improving the performance issues that JavaScript presents. New solutions have come along, with Microsoft’s Typescript and Mozilla’s ASm.js being among the solutions with representative lines.

The Ts solution is a superset of JavaScript, primarily translating strongly typed Ts into JavaScript through plug-ins, but essentially making JIT faster. Asm.js is a subset of JavaScript with variable types to maximize JIT performance. Mozilla Firefox was the first browser to implement asM.js optimization, starting with Firefox 22. Asm.js has achieved great performance improvement compared with ordinary JS, but asM. js has some problems and is not an ideal solution. Because asM.js, like JavaScript, is a text format, parsing asM.js can take a long time for complex projects, and is nothing like binary formats. At the same time, because asM. js to expand and rewrite the Math function and its own implementation also encountered a lot of problems, in order to solve these problems, a new technical solution wASM should be born.

What is a Webassembly

WebAssembly is a new extension to the Web browser. Wasm is a version-free, secure, and efficient binary format that can be called into context and browser functionality. It can be run in non-Web environments as well as in browsers.

The WASM module is always used with JavaScript “glue” code to perform useful actions when necessary. WebAssembly can be seen as an enhancement of JavaScript to make up for its lack of efficiency.

WebAssembly is a Compiler target for C, C++, Rust, Go, Java, and other languages. Binary code compiled by the Compiler does not need to Go through the Parser and ByteCode Compiler steps, and is faster than ASM.js. WebAssembly enforces static typing, is syntactically completely free of JavaScript, and has a sandboxed execution environment for better security.

Webassembly vs. Javascript performance

We compare the performance of the Fibonacci sum in WASM and Javascript respectively.

AssemblyScript is a typescript-like language. The AssemblyScript installation system includes an AssemblyScript portal. AssemblyScript uses AssemblyScript to write a function to sum the Fibonacci sequence:

export function fib(n: i32): i32 { if (n === 0 || n === 1 ) { return n; } return fib(n - 1) + fib(n - 2); } Duplicate codeCopy the code

Wasm binary files and a.wasm source file map are generated by the asbuild command. The generated code file is shown in the following figure:

The code for summation of Fibonacci numbers is as follows:

function jsFib(n){ if (n === 0 || n === 1 ) { return n; } return jsFib(n - 1) + jsFib(n - 2); } Duplicate codeCopy the code

Since Fibonacci numbers below 30 take very little time to calculate, we calculated Fibonacci numbers below 30, 35, 40 and 45 in chrome, Firefox and Opera, the three major browsers. The calculation time of Fibonacci numbers in Javascript and WASM in different browsers is shown in the following table (unit: ms) :

It can be seen from the above data that although wASM and JS have different execution times for the same Fibo number in different browsers, wASM’s execution efficiency is much higher than JS’s.

Can Webassembly replace Js

Finally, since WASM performs so quickly, will it completely replace Javascript? While JavaScript is still far behind static languages like C and C++, the performance bottleneck for most Web applications is not the JavaScript language itself, but the loading of Web resources, which Is not advantageous to WebAssembly.

Also, when it comes to developing a new feature, whether you choose to use C, C++, Rust, Go, Java or AssemblyScript, the development cost is higher than JavaScript. If the browser does not support it, it has to be relegated to JavaScript, which undoubtedly increases the business complexity. Wasm is suitable for some complex computing scenarios, such as Google Earth and Auto CAD applications on the Web are already implemented by WASM, so at least for now, WASM is not a complete replacement for Javascript.