[ffi/js-interop/wasm] Unified API for using dart:ffi and JS Interop with WASM

[dcharkes]

When developers have native code that lends itself to compilation to WASM, this native code could be used in Dart Web through JS interop.

However, we do not have a unified API for interacting with the same native library on Dart Native through dart:ffi, and on Dart Web through JS interop.

We envision such native libraries to be used in the following way:

Compile to WASM only for Dart Web, and keep using C dynamic libraries for Dart Native:

1. Dart Web: Dart <-JS interop-> JS <-> WASM
2. Dart Native: Dart <-dart:ffi-> C (package:ffigen can auto-generate bindings)

First, it would convenient if we would have a code generator that would generate the JS interop bindings for a package compiled to WASM.

Second, it would be convenient if we had some kind of unified API that could both target dart:ffi's types and the generated WASM bindings, if it would be at all possible to have a unified API. The language runtimes of C and Assembly are different, so it might not fully be possible. So this requires exploration.

(An alternative approach would be to also combine the C libraries to WASM for Dart Native:

1. Dart Web: Dart <-JS interop-> JS <-> WASM
2. Dart Native: Dart <-package:wasm-> WASM (package:wasm internally does: Dart <-dart:ffi-> C <-Wasmer runtime-> WASM.)

The downsides of this approach is having to ship a WASM runtime such as Wasmer with the Dart Native apps, and it might be slower than just using the native library. The potential upside is that the native library does not have to be cross-compiled.)

Community contributions are welcome.

Filing an issue because we don't have one tracking this yet.

[unicomp21]

Thanks @dcharkes !

The browser case is what I'm especially interested in.

I wonder if the codegen for rust typescript bindings could be useful here? It's a somewhat indirect approach (ie targetted code must be wrapped w/ rust first), but might be a way to approach the goal?

[liamappelbe]

dart-archive/wasm#34 is tracking package:wasm's support for web. No ETA on that, but the more user interest there is, the sooner we'll start working on it.

[safasofuoglu]

I'm fairly interested in getting this right. A few dozen hours of research led me to believe a truly unified ffi might be possible and could bring additional benefits. Here is my imagination of the lifecycle:

Packaging and distribution

• Native library (exposing a C API) is compiled to wasm.
• Dart ffi bindings are generated (through ffigen) from the C header of the native library.
• The compiled wasm artifact of the native library can be distributed within the pub package alongside dart bindings. This could become the only/recommended way of distributing dart native extensions.

Building

• When building for web, the library wasm file is simply included.
• When building for native, the library wasm file is AOT-compiled by the sdk and post-processed to expose the initial C API of the original library.

Running

• On native, the AOT-compiled library can be used with existing dart:ffi conventions.
• For web, additonal development is needed to use the wasm file with existing dart:ffi conventions:
  • dart:ffi to be ported to web
  • Pointer algebra to be abstracted over ByteBuffer (Wasm memory is a linear JS ArrayBuffer)
  • i64/BigInt incompatibilities to be resolved

Before going deeper, I wanted to share this excerpt to find out whether I'm moving in the right direction.

@dcharkes @mraleph @mit-mit @askeksa-google would love your thoughts.

[mraleph]

@safasofuoglu

The compiled wasm artifact of the native library can be distributed within the pub package alongside dart bindings. This could become the only/recommended way of distributing dart native extensions.

When building for native, the library wasm file is AOT-compiled by the sdk and post-processed to expose the initial C API of the original library.

I don't think that's a good way - WASM gives you certain degree of portability, but it abstracts you from the underlying platform and puts your code into a sandbox - meaning that your code can no longer access specific platform features or APIs. This is rather limiting e.g. cryptographic library might contain hand written platform specific assembly for performance and security reasons, or library might be talking to OS specific APIs. Source code (or platform specific binaries) is a much more flexible distribution format for arbitrary libraries than WASM.

[safasofuoglu]

@mraleph thanks.

your code can no longer access specific platform features or APIs

This can be (partially) resolved by linking with WASI-libc (and WASI polyfills for the web). It won't support OS specific APIs.

might contain hand written platform specific assembly for performance and security reasons,

Hand-written assembly is a no-go, but most SIMD intrinsics can be ported. I was able to compile the complete dart sdk with all dependencies (boringssl, zlib etc) through emscripten, with simd intrinsics where supported. Unable to run anything, but it compiles.

Source code (or platform specific binaries) is a much more flexible distribution format for arbitrary libraries than WASM.

No doubt. However, in case of pub, distributing binaries is a problem (#36712) and distributing source code means additional compiler dependencies and a wrapping build-runner (https://crates.io/crates/cc).

Hence, I was wondering whether a unified wasm+ffi approach might cover a good percentage of use cases to be preferable.

[dvc94ch]

This project already supports generating dart and js for rust projects [0]. I'd suggest going with compiling flutter/dart to wasm and then linking using the wasm linker is probably a better long term solution. Once flutter/dart compile to wasm I can add support to ffi-gen. For this to work nicely there needs to be a way to link flutter/dart binaries using the system linker as in #47718

• [0] https://github.com/cloudpeers/ffi-gen