Write WebAssembly module loader

[mjethani]

Background

We would like to start moving some of our code to WebAssembly if and where possible as we run into our limits of what we can do with pure JavaScript (#7000). This would be somewhat in parallel to the Emscripten effort, but could also be seen as a way to gradually migrate to that implementation over time. In any case, the lessons learnt from the Emscripten effort would come in handy in this piecemeal migration.

The first step for doing this is to have a loader that can load a WebAssembly version of a module on platforms that support it and automatically fall back to a pure JavaScript implementation otherwise, based on a mapping somewhere. This mapping could be in the build script, for example, or it could be hardcoded into the source of the module.

These days it's easy to load a WebAssembly module using a few lines of JavaScript:

<script>
  function loadModule(path)
  {
    return fetch(`${path}.wasm`).then(response => response.arrayBuffer())
           .then(bytes => WebAssembly.instantiate(bytes))
           .then(object => object.instance.exports);
  }

  loadModule("simple").then(({add}) =>
  {
    console.log(add(1, 2)); // prints 3
  });
</script>

It would be easy to modify the above implementation to fall back to require'ing the pure JavaScript version of the module if the .wasm file is not found or if WebAssembly is not supported on the platform, while keeping it transparent to client code.

It is also trivial these days to write WebAssembly, even ​by hand:

;; simple.wat

(module
  (func (export "add") (param i32) (param i32) (result i32)
    get_local 0
    get_local 1
    i32.add
  )
)

This can be compiled to a WebAssembly binary using ​WABT:

wat2wasm -o simple.wasm simple.wat

There are higher-level languages and frameworks being built around this (e.g. ​Walt). The web is no longer so tightly coupled with JavaScript.

As a first step, we need a WebAssembly module loader that falls back to alternative pure JavaScript implementations based on certain criteria.

Compatibility

(What versions of Chrome, Firefox, and Edge is WebAssembly supported on? What are the details we need to know before we start work? To be filled out.)

What to change

To be determined.

[hfiguiere]

Issue #6312 is for the emscripten branch

[hfiguiere]

Support matrix:
​https://developer.mozilla.org/en-US/docs/WebAssembly

No IE, Edge 16, Chrome 57, Firefox 52

[hfiguiere]

Also we don't need C++ to write wasm code. We can do it in Rust.

[mjethani]

Based on the little that I know about Rust, I would very much prefer it over C++.

[mjethani]

Replying to mjethani:

Based on the little that I know about Rust, I would very much prefer it over C++.

Seriously though, there are two things we would have to consider:

1. Skills: Do we have the skills in the team? Anybody can write a "Hello world" program in Rust, but it takes a long time to master a language. In order to get the best out of it, one really must grok it. We have some very skilled C++ programmers on the team with lots of experience.
2. Performance: If we're going to adopt WebAssembly as a target for performance reasons, we should try to get the best tradeoff between performance and maintainability. The question is whether Rust can be compiled to WebAssembly bytecode as optimally as C++.

[hfiguiere]

Replying to mjethani:

The question is whether Rust can be compiled to WebAssembly bytecode as optimally as C++.

Yes.

[mjethani]

This will actually have to be part of buildtools. We will need a custom webpack loader that loads the WebAssembly version of a given module if it's available and fall back on the JavaScript version otherwise. The WebAssembly binary would be included in the generated lib/adblockplus.js by the build script as a byte array.

We need to work out the details.

[hfiguiere]

I think we could start by doing it for the emscripten branch, and then we can move that patch to the main branch when needed/wanted.

[Himanshu0709]

spam

[sebastian]

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the ​new issue tracker.