intent to discontinue

[devoncarew]

Hi - this issue is a heads up that we intend to discontinue this package and archive the repo.

This package was an experiment in consuming WASM code - integrating a WASM runtime into applications, allowing them to leverage existing native libraries compiled to WASM. While this is still an interesting path to explore, generally as a team we're investing in producing WASM from Dart - letting a Dart based app run in a WASM runtime (ala Flutter Web in a browser). See https://docs.flutter.dev/platform-integration/web/wasm for more information.

As a reminder, our general SLO for packages in the labs.dart.dev publisher: "For packages in the labs.dart.dev publisher we generally plan to either graduate the package into a supported publisher (dart.dev, tools.dart.dev) after a period of feedback and iteration, or discontinue the package."

This package was last published about 2 years ago, and last actively worked on about 1 year ago. For people who do wish to continue to experiment with a similar technique to package:wasm / leveraging a wasm runtime, please feel free to fork this repo.

cc @liamappelbe @a-siva @kevmoo

[liamappelbe]

cc @modulovalue

[juancastillo0]

Hi

I have been working on a package that provides similar functionalities, perhaps if anyone is interested they could try it out. It uses the wasmtime runtime and the wasmi interpreter. I just published it yesterday https://github.com/juancastillo0/wasm_run. If anyone would like use it or share some feedback that would be great!

It can compile and execute wasm using wasmtime and, for platforms that do not support it (iOS), wasm_run will use the wasmi interpreter. The primary reason to implement a different package from package:wasm was to support all platforms. It also supports the web using the browser's runtime and package:wasm_interop. WASI is supported in all platforms (including web with an in-memory file system). It uses flutter_rust_bridge to generate the native bindings and we also provide package:wasm_run_flutter that fetches the right binaries for each platform.

There is also a work-in-progress package:wasm_wit_component to generate Wasm Interface Types (WIT) bindings for Dart, which significantly improve the interop story. An example is the wit parser and generator itself that is implemented in Rust and compiled to a wasm module that follows a WIT package definition. package:wasm_run, with the bindings generated from the WIT file, executes the wasm module in the dart run wasm_wit_component:generate CLI to generate the Dart code from wit files.

Thanks for all your work!

[modulovalue]

Thank you for the heads-up.

@devoncarew I think that this package should not be archived because many challenges that this package has to overcome don't seem to have a good solution yet and are actively being worked on by others (e.g. #116 by the WIT efforts, #127 by e.g. wasmtime). I believe there are still too many open questions over which neither the Dart teams nor the Dart ecosystem has any control over and I think it would be best to just wait and see how the WASM ecosystem continues to evolve first.

There seems to be a lot of momentum behind WASM as a technology and (everybody seems to be on the WASM-train). I think that archiving this package would send a pretty negative signal to everybody. I personally wouldn't mind if this package goes into hibernation for another year.

[liamappelbe]

These are the main challenges I see that need to be overcome:

• It's hard to ship packages with native code in the Dart ecosystem. We wrap the Wasmer runtime, which is a Rust library, so that makes it pretty inconvenient to use this package at the moment. I also never got the Wasmer build working for iOS. We're working on solving this problem independently of this package, through the native assets CLI. Once that lands, it will be much easier to use this package (no more manually running the build script). This should also solve the iOS build issues.
• As you mentioned, there's no JIT on iOS. One solution to this is to use Wasmer's AOT mode. An older version of this package supported that, but I removed it because it didn't work quite as I expected and needed a redesign (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 😕). Alternatively an interpreted runtime could be used (Wasmer probably has a mode for that).
• For generating bindings, that should probably be a distinct package (like how dart:ffi has package:ffigen).

I don't really see how keeping this package alive helps resolve these issues. I can see clear solutions to each of these that are either already possible, or actively being worked on. I don't see anything else in this package that requires input from the Dart team specifically. So, there's no reason this package can't be forked and maintained by the community.

It makes more sense for the Dart team to focus our efforts on the things that require changes at the VM level, or are otherwise foundational, like the native assets CLI I mentioned, or my current async callbacks project. These are changes that will improve interop with all languages, not just wasm.

Although we're deprecating this package, we're definitely not ignoring wasm. Quite the opposite. Compiling Dart/Flutter to wasm is actively being worked on, and was demoed at IO.

@modulovalue I encourage you to fork this package, make all those API changes you were trying to land in this package, then publish it yourself (under a different name, to avoid confusion).

[modulovalue]

I think there are no fundamental disagreements here, it's just that there is a difference in opinion about what to focus on.

It seems to me that a big reason why dart is not being adopted more is its lack of well-tested and proven-in-production packages. C, Python, JS/TS, Java/Kotlin all have huge ecosystems that are orders of magnitude bigger than the Dart ecosystem.

WASM is like the "grand unified interface" of interoperability within the software development community and essentially everybody is on board. I think that the Dart ecosystem could immensely benefit from being able to execute WASM as this could help it close this ecosystem gap.

Of course, I can't force anyone to do anything. I just hope that this opinion has been considered. cc @kevmoo @mit-mit

I encourage you to fork this package

I will most likely have to do that. Unfortunately, I don't have the resources to develop and support a general purpose solution for the whole community that supports all platforms.

[mit-mit]

We're quite aligned on the importance of interop, and you might have noticed our recent efforts on things https://dart.dev/guides/libraries/c-interop, like https://dart.dev/guides/libraries/java-interop and https://dart.dev/guides/libraries/objective-c-interop.

However, there is only so much we can cover, so we're trying to focus on things that are at the lowest level of abstraction and thus have to be in the SDK itself. Something like the present package is at least technically setup to be at a higher level of abstraction, and we're hoping that the wider community might take it on.

[devoncarew]

WASM is like the "grand unified interface" of interoperability within the software development community

Yeah, I completely agree here. Wasm can help solve the many-to-many problem for algorithms; if you can consume wasm in your language or runtime, you can take advantage of all the best of breed algorithm implementations authored in other languages (for compression, image codecs, crypto, I18N, ...).