Provide interop between Dart and WASM

[bryanrideshark]

Would it be possible to enable Web Assembly in Dart?

Were this to be possible, I think it would greatly increase investment in the language as existing codebases would have a common compile target which could be used as a bridge.

For example I'd love to use Dart/Flutter but doing so would be incredibly costly without much benefit. Were I able to use WASM in Dart however the story would be very different- Flutter would become just as easy to use as any other web interface were that the case.

Can we get an up/down on whether or not this is A possible, and B something the team would like to support in the future?

[lrhn]

As I see it, supporting Web Assembly is not a language feature. It doesn't require any new language features, and since it's only available on the web, we would cautious about adding platform specific syntax. All it needs is a way to communicate with JavaScript, which we already have in JavaScript interop.

I'll move this question to the SDK repository and make it a question for the Dart-for-web team, who are in charge of JavaScript interop: Can they include WASM interop in dart:js or package:js?

[lexaknyazev]

A package for accessing raw WASM API from JS exists:
https://pub.dev/packages/wasm_interop

common compile target which could be used as a bridge

Emscripten-compiled modules always require additional JS glue to do initialization and to pass any function parameter or return value that is not a number. So an actual interop would be between dart2js compiled JS and emscripten-supplied JS (which is already possible via existing JS-interop options).

Compiling Dart code to WASM may be interesting for some use cases but the final result would look like what emscripten does: a WASM module with auto-generated JS glue. So again, an actual interop would be between two JS codebases.

[srawlins]

CC @yjbanov @mraleph @matanlurey

[mraleph]

Could you clarify what you mean by "Web Assembly Support" because there are multiple different things this could mean, for example:

• You want to be able to use WASM on the Web together with Dart
• You want to be able to use WASM in native environments with Dart (e.g. on command line, Flutter apps, server)
• You want to be able to compile Dart to WASM

For example I'd love to use Dart/Flutter but doing so would be incredibly costly without much benefit. Were I able to use WASM in Dart however the story would be very different- Flutter would become just as easy to use as any other web interface were that the case.

It is not really clear to me why any form of WASM support makes it easier for you to use Flutter.

You can already use any native language in your Flutter application, you don't really need any WASM support for that. Of course you need to figure out interoperability story because Flutter framework is written in Dart so it works best when actually used from Dart and not from some other language.

Say you want to use Flutter class StatefulWidget from C++ code - how is this supposed to work? What does it even mean? WASM does not magically answer this question.

[vsmenon]

Since we have an issue ( #32894 ) for compilation, let's use this for interop. We may want to split the native and web cases ( @mraleph 's first two bullets) at some point, but one use case might be deploying / sharing C++ components between Web and native targets.

[sffc]

We are interested in Google i18n about using WASM in native environments with Dart. See #32894 (comment)

[kevmoo]

@nex3 – do you already have an issue open on this?

[nex3]

@kevmoo I don't think so.

Using WASM from Dart is something I'm interested in seeing as someone with a vested interest in Dart's success. WASM is extremely portable (any language could add support for it, and it's usable in the browser), it will provide a clearly-defined interop interface for high-level languages, and it's likely to be quite performant for algorithmically-intensive code. This combination positions it very well for becoming the de facto standard platform for self-contained libraries. Library authors are motivated to target WASM because it'll make their libraries easy for downstream users across all manner of languages and platforms to use, and languages will be motivated to support it because so many libraries exist. The normal bootstrapping problem a network effect like this will be smashed by having support from the two most widely-used platforms, Node.js and the browser, from the word go.

If Dart gets ahead of the curve and starts adding support for WASM now, it'll have access to (and input into) this ecosystem as it grows, making it easier and more attractive for new users to move to Dart. But if you wait until WASM support is de rigueur for any serious language, you'll have to exert the same energy playing catch-up that could have instead been a competitive advantage.