[proposal][wasm][ffi] AOT wasm interoperability

[iapicca]

Use case

wasm interoperability would offers great value to flutter's framework
I'm sure the team is aware of this [1, 2] given that there used to be a labs.dart.dev's package wasm
that was discontinued in summer 2023;
according to this comment such decision was caused by 3 technical obstacles:

• lack of dart/flutter native assets feature
• lack of AOT mode of the wasm runtime of choice for ios
• need for a separated package for bindings

as of today there is visible momentum towards the clearing of the main obstacles

• dart has an experimental native assets feature
  • ☂️ [vm/ffi] Native assets feature dart-lang/sdk#50565
  • ☂️ Native assets support #129757
• wasmedge besides provide support for several platforms is working on wasm AOT fro android and ios
  • AOT feature support iOS/android make Wasm as universal binary WasmEdge/WasmEdge#2621

Proposal

Track the clearing of technical blocker for a wasm implementation
and if/when these blockers are cleared resume/re-work the deprecated package:wasm

cc @devoncarew @mit-mit @liamappelbe @hydai

[dcharkes]

@iapicca What are you asking for? Being able to call into WASM code from a native backend? Or being able to compile Dart to WASMGC and calling into WASM from Dart when Dart is being compiled to WASM? What use case do you want to solve?

(My current thinking is that if you have native code, then it can be compiled to a dynamic library for the native backends, and to wasm (via emscripten) for web backends. And then we need support for calling WASM code from the WASMGC backend possibly via dart:ffi. We've explored such approach in dart-lang/native#1390 which compiles libclang to WASM. So this is a completely different approach than bundling a WASM runtime in the Dart native backends. It's more in line with dart-lang/sdk#46690.)

[iapicca]

@iapicca What are you asking for?

to be able to call WASM code on all platforms supported by Flutter
similarly to the discontinued package wasm
that supported android, ios, linux, windows and mac (hilariously not web),
but with few differences:

• AOT wasm runtime
• native assets
• web support

Being able to call into WASM code from a native backend?

yes, on all platforms

Or being able to compile Dart to WASMGC and calling into WASM from Dart when Dart is being compiled to WASM?

Given that AFAIK at the time of writing Dart compiles to WASM only for flutter web, then yes
the expectation that a wasm backend would work on all platforms including flutter web when compiled to wasm

Use case

wasm interoperability would offers great value to flutter's framework I'm sure the team is aware of this [1, 2]

What use case do you want to solve?

to be able to call WASM code on all platforms supported by Flutter (see above)

(My current thinking is that if you have native code, then it can be compiled to a dynamic library for the native backends, and to wasm (via emscripten) for web backends.

I don't assume native code as a starting point,
WASM doesn't need to be compiled for a specific "native platform" as the same code will run by default everywhere.

Yes, there is a need for a runtime and picking one will be an interesting choice to make
I mentioned WasmEdge because its work toward
android and ios support that could alleviate the effort of the team in that regard

And then we need support for calling WASM code from the WASMGC backend possibly via dart:ffi. We've explored such approach in dart-lang/native#1390 which compiles libclang to WASM. So this is a completely different approach than bundling a WASM runtime in the Dart native backends. It's more in line with dart-lang/sdk#46690.)

I'm sure it could work, but it feel a bit "artisanal", no offense.
I'm aware of web packages that already use wasm (eg: drift and see issue),
moreover having to manually wire native code to flutter for each platform defeats the purpose.
What I'm proposing is provide a tool that allows developers to call a wasm code from all supported platforms,
by embedding (as a federated plugin) the wasm runtime of choice
and bridge dart <-> wasm calls through code generation

@dcharkes
I noticed that in this issue

• [ffi/js-interop/wasm] Unified API for using dart:ffi and JS Interop with WASM dart-lang/sdk#46690

you mention the use of wasm package that is discontinued

Dart Native: Dart <-package:wasm-> WASM (package:wasm internally does: Dart <-dart:ffi-> C <-Wasmer runtime-> WASM.)

I'm essentially proposing to replace it (or resurrect it)
with a newer and better version (native assets + AOT runtime + codegen)
so this seems to fall in line with your proposal

[CodeDoctorDE]

I'm also interested in this. WASM could be a good library. You could just use wasm packages like npm packages and use it on all platforms.

I'm also interested if this could also be in a secure environment, to allow something like a plugin system inside a flutter app.
You could just add a wasm interface to your app and allow users to install any plugin they like which is written in WebAssembly.

[iapicca]

I'm also interested if this could also be in a secure environment, to allow something like a plugin system inside a flutter app. You could just add a wasm interface to your app and allow users to install any plugin they like which is written in WebAssembly.

I don't think this is possible on all platform, basically ios forbid it (and some android as well?)
the code needs to be bundled and AOT AFAIK
there are WASM interpreters that don't have horrible performances, but I suspect it wouldn't be accepted

[CodeDoctorDE]

I would just keep it to the developer.
On desktop and on apk builds this should be no problem. VSCode has something like this with javascript and securing should be just an option? This shouldn't be a downside for bundled wasm plugins.

[iapicca]

In the issue description I specify the need for a native asset,
for how I see it an implementation based on dynamic asset is out of the scope of this issue

[syrusakbary]

Some statements on this issue are incorrect. Wasmer did support AOT at the moment of discontinuation, and you can already run Wasmer in iOS and Android.

Quoting from the original comment:

Wasmer's AOT compiled wasm modules are not cross platform, so we'd need to figure out cross compilation to target iOS etc, and now we're back to shipping binaries per platform

The main issue was that the compiled module AOT was not cross-platform (for example, you could not reuse the same compiled module for x86 Windows in ARM64 iOS). This problem exists in any sandalone Wasm runtime that is not Wasmer at the moment.

That specific issue is, however, solved since the interpreter support we added in Wasmer 5.0.

[iapicca]

Some statements on this issue are incorrect. Wasmer did support AOT at the moment of discontinuation, and you can already run Wasmer in iOS and Android.

Quoting from the original comment:

Wasmer's AOT compiled wasm modules are not cross platform, so we'd need to figure out cross compilation to target iOS etc, and now we're back to shipping binaries per platform

The main issue was that the compiled module AOT was not cross-platform (for example, you could not reuse the same compiled module for x86 Windows in ARM64 iOS). This problem exists in any sandalone Wasm runtime that is not Wasmer at the moment.

That specific issue is, however, solved since the interpreter support we added in Wasmer 5.0.

@syrusakbary
I'm happy to stand corrected, this is great news,
so if I understand correctly the missing pieces of the puzzle are

1. native asset

• dart has an experimental native assets feature
  • ☂️ [vm/ffi] Native assets feature dart-lang/sdk#50565
  • ☂️ Native assets support #129757

2. set up ffigen to be used with wasm

3. unified api for ffi/js/wasm

• [ffi/js-interop/wasm] Unified API for using dart:ffi and JS Interop with WASM dart-lang/sdk#46690

am I missing something?
cc @dcharkes

[mraleph]

I continue to maintain an opinion that direct first party interoperability with Wasm across all surfaces supported by Dart should not be part of Dart (or Flutter) SDKs. It should exist as a third party package / tooling. And we should make sure to accommodate the needs of such package tooling in low level capabilities of the platform.

It does seem to me that native assets (and associated build/link/packaging hooks) should be good enough for people to be able to build and publish their version of package:wasm - once we ship native assets.

So my suggestion here would for people interested in this sort of thing - to start designing, building and experimenting, and provide feedback to the Dart and Flutter teams.

I have heard various pitches trying to explain why Dart/Flutter should have this and none of them are persuasive enough (or have sufficient ecosystem momentum behind them):

• "what if Dart packages could just include Wasm, then they could work across all platforms without any additional work" is one of them. I understand the appeal but I think the benefit is exaggerated. Targeting mobile platforms requires native toolchains anyway to do anything remotely sophisticated and installing and managing these toolchains is relatively straightforward. Consequently Wasm becomes just an overhead/additional dependency on Wasm runtime - rather than some sort magical portability solution: instead of going directly to native code targeting specific mobile platform, you go to Wasm and then through Wasm AOT compiler to native code (or worse - you are going to interpret Wasm module in runtime leading to worse performance, higher battery usage, etc.
• Wasm is a foundation for dynamic modules. Here the main question is what is going to be in those modules and why you want them to be dynamic?

[bkonyi]

I don't think this is relevant to the tools team right now since it's a proposal for a larger Dart / Flutter feature, so I'm going to remove the team-tool label.