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?
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?
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.
CC @yjbanov @mraleph @matanlurey
Could you clarify what you mean by "Web Assembly Support" because there are multiple different things this could mean, for example:
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.
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.
We are interested in Google i18n about using WASM in native environments with Dart. See https://github.com/dart-lang/sdk/issues/32894#issuecomment-513325349
@nex3 鈥撀燿o you already have an issue open on this?
@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 fact 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.
I was more wanting to use WASM inside Dart, in a mobile Flutter app. I maintain a large enterprise codebase which must be able to work in the browser; Moving to Flutter is simply not feasible, because as it stands, it would require an entire rewrite of important business logic, etc.
If I could use WASM to contain my business logic etc. then I could easily move to a Flutter app as I would need to do, is import the appropriate WASM module.
Actually @bryanrideshark as far I can tell Dart will support wasmerio for loading web assembly modules, so you don't have to be worry about that. I think it is behind an experimental flag on master.
I'm guessing that @sachaarbonel you mean #37882 so this is very exciting to see support for wasm libraries coming to Dart and I assume eventually to Flutter?
Yep exactly @maks
you mean wasmvm on dart?
i need this too
For everybody tracking this issue. We are currently evaluating how to move multiplatform Dart<->WASM interop forward. Similarly to our C FFI work we would like to collect some examples of code that people would like to use in their Dart applications via WASM. So if you have one that is open source please leave a comment here or on #37882 with a link to the source and which platforms you would like to use it on (Flutter on iOS/Android/Desktop/Web, Dart Web), please also include information if you have ever tried running this library in WASM before. Thank you.
The i18n Engineering team at Google is building a cross-platform standard i18n library, which we intend to make available via WASM (internal link http://go/omnicu, public link http://bit.ly/omnicu-charter). Dart supporting WASM would be a big boost.
Another use case separate from i18n that I'm interested in is to use 2D graphics libraries, such as Cairo. I have not done it personally, but a quick Google search brings up a few different examples of how to use Cairo on the web via WASM.
That's awesome @sffc. We are working on bringing universality to the WebAssembly modules, integrating Wasm into multiple languages (we already have integrations for Python, PHP, Rust, Ruby, Elixir, C#, Go, C, C++...)
Would be great to chat and see how we can make omnicu usable from all this languages, including Dart as well!
Here's my email, in case is useful for following up [email protected] :)
Would be nice to use in combination with skia canvaskit so that we can have flutter support for web based designops tools like storybook.
@codemasterover9000 FWIW you can use CanvasKit as the rendering backend in Flutter on the Web already (still experimental though). All you need to do is pass --dart-define=FLUTTER_WEB_USE_SKIA=true
to flutter run
or flutter build web
. When you use the normal Canvas
and SceneBuilder
we'll use CanvasKit behind the scenes.
Most helpful comment
@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 fact 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.