doubt

  1. What is WebAssembly?

  2. What problems does WebAssembly solve?

  3. What are the applications?

  4. What’s the problem?

  5. What does it bring to the front end?

  6. Browser support?

1. What is WebAssembly?

A WebAssembly is a technical solution that can be written in a non-javascript programming language and run in a browser.

2. What problems does WebAssembly solve?

Break through the bottleneck of performance

There are no technical issues involved here. We know that in today’s browsers, JavaScript is executed inside a virtual machine (VM) that maximizes code and squeezes every bit of performance, making JavaScript one of the fastest dynamic languages. But despite that, it’s not as good as native C/C++ code. So, WebAssembly came along.

Wasm also runs in a JavaScript virtual machine, but it performs better. The two can interact freely and mutually, so you have the best of both worlds — JavaScript’s huge ecosystem and good syntax, and WebAssembly’s near-native performance.

Most programmers will choose to write WebAssembly modules in C and compile them into.wASM files. These. Wasm file and cannot be directly identified by the browser, so they need a called JavaScript glue joint code (glue code, used to connect each other incompatible software components, see: whatis.techtarget.com/definition/…). Things to load.

3. What are the applications?

  1. Data encryption

  2. Web game

  3. Intensive computing

4. What’s the problem?

  1. It’s browser compatibility.

  2. WebAssembly does not have automatic garbage collection (requires manual handling)

  3. The API is not stable yet

5. What does it bring to the front-end?

Wasm is a good thing, but it won’t replace JS.

Officially, WASM is not a javascript replacement, it works with javascript and complements the Web platform. So there’s the WASM JS API. You can think of WASM as an accelerator for JS.

Wasm does not yet support dom access, and in the future there are plans to have WASM call javascript to call JS-supported apis, since WASM cannot call web apis. When WASM can call javascript, with javascript glue code to help WASM call webAPI, wASM can even do without javascript (except load WASM and load glue JS dependencies) and complete the web application. It’s probably too expensive to implement webapi directly in c++, so if every language implements webapi, it’s better to implement glue.

Obviously, this mechanism allows c++ (or any other language) to implement web applications directly, and the actual language bottlenecks are minor compared to dom manipulation bottlenecks.

Wasm implements SDL, OpenGL, OpenAL, and some POSIX in c++. The code still has to run on the client side, so you can see that a lot of functionality is actually being neutered. Fortunately, OpenGL can run on canvas, so I think wASM will improve the development of H5 games.

Guess Future

  • H5 games have a lot of potential with WASM and even pWA to allow H5 games to handle heavier scenarios.

  • Impact on JS, given the current share of JS (high), the flexibility of JS (high), and the current bottleneck of most JS Web applications (no obvious bottleneck), the current situation is not enough for the team to devote energy to this matter.

  • Enterprise products may invest elite manpower in WASM applications, which can improve the experience of enterprise web applications.

  • The agility, manpower, and product bottlenecks required by the C-side business and activities do not allow teams to work with WASM. It’s hard enough to hire a decent JS.

6. Browser support?

Support for WebAssembly is beginning to be almost universal in new versions of major browsers

7. To summarize

WebAssembly executes faster than JavaScript because:

  • WebAssembly is faster than JavaScript in the file fetching phase. WebAssembly files are smaller than JavaScript even when JavaScript is compressed;

  • In the parsing phase, WebAssembly’s decoding time is shorter than JavaScript’s parsing time.

  • During compilation and optimization, WebAssembly has an advantage because the WebAssembly code is closer to machine code, whereas JavaScript is optimized on the server side first.

  • During the re-optimization phase, WebAssembly does not re-optimize. However, the optimization hypothesis of JS engine may occur the phenomenon of “discarding optimized code <-> re-optimization”.

  • At execution time, WebAssembly is faster because developers don’t have to know as much about the compiler, which is required in JavaScript. WebAssembly code is also better suited to generating instructions that the machine can execute more efficiently.

  • In the garbage collection phase, WebAssembly garbage collection is manually controlled and more efficient than automatic collection.

References:

  1. Does WebAssembly mean the end of Javascript?

  2. WebAssembly Practices: How to Write Code

  3. Get C code running in a browser – Introduction to WebAssembly discussion address: Document your learning problems, document your growth