Compile Dart to Wasm

[listepo-alterpost]

It would be very cool to add support for the WebAssembly

---

Admin comment: For current status, see https://dart.dev/web/wasm

[terrylucas]

Yes it would. This is something we are looking at. Thank you.

[Bohne13]

What, is the effort of webassembly and is there a timeline, for implementation?

[mraleph]

There is no timeline and no work is happening on this at the moment.

[listepo-alterpost]

@mraleph thanks for answer, but how can I know that already happening?

[mraleph]

@listepo-alterpost I am not sure I understand the question. Nothing is happening on this at the moment.

[b-strauss]

Using this in flutter apps would be a great usecase.

[mraleph]

@b-strauss using it in what way?

[listepo-alterpost]

I guess like Blazor alternative(Hummingbird)

[b-strauss]

@mraleph

WebAssembly is a cross platform format. If the DartVM had support for it, we could use the same WASM files on mobile Flutter apps as on web Flutter apps (with Hummingbird via calls to the JS WASM API).

[mraleph]

@b-strauss There is definitely no plans to support running WASM binaries on Dart VM. You can run native code on mobile platforms - which means you can run anything you want and you don't need to compile to WASM first.

[b-strauss]

@mraleph You're right of course. But seeing that the target platforms for flutter will grow in the future (Web, Windows, macOS, fuchsia), having a single binary would make targeting these definitely easier. But I'm aware the cost for that would be high. ;)

[Lelelo1]

Any news on this?

[mraleph]

No news.

In general if you are interested in WASM support I recommend including rationale (e.g. "I am interested in WASM because ..."). Knowing use cases that people consider would help us to prioritise things. Thanks.

[Schonhoffer]

I am interested in WASM because ..

• I have an existing SPA web app that relies on substantive library that isn't really JavaScript specific, but needs to run client side.
• I want to develop a mobile app with same experience using Flutter, and would have to re-write and maintain a duplicate of this library in Dart alongside the existing JavaScript implementation.
• I would like to be able to re-write that library in a language that targets WASM, and then be able to import that library from both web platform and flutter.

TLDR: code sharing of packages between client-side web & flutter.

[mraleph]

@Schonhoffer You can already do this in multiple ways:

• First option: Dart actually compiles to JavaScript - so if you just rewrite your library in Dart you will be able to use it from both JavaScript and natively from Flutter. [and if you are rewriting it anyway - why not in Dart?]
• Second option: Dart allows you to interoperate with native libraries from Flutter (and this will get even better with FFI that is currently under active development). So you write your program in some native language like C++ (or Rust), compile it natively and use it from Flutter. You can also compile it to WASM and use it on the Web.

As you can see neither of these options requires any sort of WASM support from Dart.

[nex3]

Dart Sass is also very interested in WebAssembly. Our biggest user base runs Dart Sass on Node.js, but we consistently hear from our users that the performance of the compiled JS output is not up to par. Our users are comparing the performance of our dart2js output to Node Sass, which is a wrapper around a C++ library. Dart Sass via dart2js is 2x slower than Node Sass in the very best cases, and almost 6x slower when compiling some real-world libraries.

On the other hand, the main reason anyone uses Dart Sass over Node Sass is that it's vastly easier to install a library that doesn't require native compilation. So users have a choice: they can have an easy installation experience or fast compilation, and whichever they choose also comes with a bunch of subtle incompatibilities. It's not a great experience.

WebAssembly would give us the best of both worlds. It would almost certainly represent a major performance boost over dart2js because we don't have to deal with the overhead of JavaScript, and it's just as portable (and thus easy to install) as plain JS. Even if it the WASM binary had to ship with a full garbage collector until WASM supported it, it would make a huge difference to me and my users.

---

As an aside, can we re-open this issue, since the proposal is still under consideration?

[Bohne13]

For all of you:
in the following link is a survey about flutter directly from the flutter developers. Because Flutter and Dart are closely linked together there are some questions about Dart and one particular about dart support for web assembly.
Could be interesting?!

https://google.qualtrics.com/jfe/form/SV_3W3aVD2y9CoAe6V?Source=IntelliJ&ClientID=cc844799-def7-4db0-8e50-d20606f2af1d

[alanjds]

"Sorry, this survey is not active"

[alanjds]

@mraleph The point is about easy interoperability. I can compile Rust/C/C++ to native, but having a to deal with this for every platform is cumbersome and unecessary on early versions of my app.

Do this makes any sense?

[pie-flavor]

That and "it already compiles to JavaScript" is not really a big comfort because one of the main perks of using wasm instead of transpiling to JS is the incredible speed increase.

[mraleph]

I am reopening the issue to indicate that this is something we are considering, even though we currently have no immediate plans to work on this.

@pie-flavor

one of the main perks of using wasm instead of transpiling to JS is the incredible speed increase.

WASM is not some pixie dust that makes your code magically faster. I actually have some serious doubts that compiling Dart to WASM would bring any speed increase, and in fact expect worse performance due to the lack of dynamic optimizations, insulation from underlying native architecture and inability to rely on builtin optimised primitives and standard library. The only performance characteristic that can potentially be improved by targeting WASM is startup latency. Additionally you will get somewhat predictable performance - but again, I actually doubt it would be better than peak performance you will get from good dart2js code.

[b-strauss]

I am reopening the issue to indicate that this is something we are considering, even though we currently have no immediate plans to work on this.

@mraleph Are you talking about running WASM binaries on Dart VM, or compiling Dart to WASM?

[mraleph]

@b-strauss renamed issue to make it clear.

[b-strauss]

@mraleph Is running WASM on the Dart VM also something that is considered? Should there be a separate issue for that?

[StEvUgnIn]

This developer @NachoBrito actually shows that Dart needs to focus on Webassembly instead of JavaScript. JS Interop needs work to support the new HTML5 APIs:
https://github.com/NachoBrito/flutter-multiapp-poc/blob/main/component1/web/js/interop.js

[unicomp21]

Will dart webassembly support using the upcoming tail call support? My reason for asking. Looking at the "out of order execution" supported by modern cpu's, will tail call's essentially allow us to await cache line misses? And run something else in the meantime where the cache lines have been loaded?

[kevmoo]

Will dart webassembly support using the upcoming tail call support? My reason for asking. Looking at the "out of order execution" supported by modern cpu's, will tail call's essentially allow us to await cache line misses? And run something else in the meantime where the cache lines have been loaded?

@askeksa-google ?

[askeksa-google]

Will dart webassembly support using the upcoming tail call support? My reason for asking. Looking at the "out of order execution" supported by modern cpu's, will tail call's essentially allow us to await cache line misses? And run something else in the meantime where the cache lines have been loaded?

The tail call instructions are just fused call-and-return instructions that pop the caller's stack frame before pushing the callee's stack frame. While this is a useful primitive in some coroutine implementations, the tail call instructions do not by themselves confer any capability to suspend and resume the execution of a function body. Such capabilities are being discussed as part of the Stack Switching Proposal.

Dart has the sync* feature for writing generator functions, which have the capability to be suspended and resumed somewhat similarly to what you suggest. The current implementation of these in the Wasm backend (and in the other backends as well) has some significant overhead associated with it, though, mainly from having to keep the local state of the function alive in heap objects across suspension points. A future Wasm-level stack switching feature could potentially reduce some of that overhead.

[unicomp21]

@askeksa-google I'm confused. Why are the leaningtech guys realizing large performance boosts by having tail calls?

https://leaningtech.com/extreme-webassembly-2-the-sad-state-of-webassembly-tail-calls/
https://leaningtech.com/fantastic-tail-calls-and-how-to-implement-them/

[askeksa-google]

Maybe I misunderstood what you wanted to do with the tail calls. It's certainly feasible to add an option to emit tail calls whenever the result of a call is directly returned. This will make stack traces different from what would be expected from the Dart source, but this is already the case for other optimizations, such as inlining.

It may indeed improve performance in some cases. I don't see what it has to do with hiding cache misses, though.

[unicomp21]

@askeksa-google In talking w/ some of the redpanda engineers, my understanding is c++ co_await essentially makes cache line misses "await'able". Another strand/coroutine can be resumed where the cache line has been loaded.

Per Gor, tail calls are required in order to support co_await in webassembly. I'm wondering if dart await can perform as efficiently as c++ co_await, in webassembly?

https://www.youtube.com/watch?v=_fu0gx-xseY&t=11s

[liudonghua123]

flutter 3.10 and dart 3.0 is released with some wasm support, how can I compile dart code to wasm in 2023?

I also noticed https://pub.dev/packages/wasm, but it is about loading wasm module in dart, not compile dart code to wasm module.

[kevmoo]

@liudonghua123 we're not ready to release things beyond preview.

Keep in mind, all of the runtime support for WasmGC is also in preview.

https://flutter.dev/wasm has the latest details

[liudonghua123]

@liudonghua123 we're not ready to release things beyond preview.

Keep in mind, all of the runtime support for WasmGC is also in preview.

https://flutter.dev/wasm has the latest details

Thanks, I also found some docs on https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm.

[iapicca]

@kevmoo
will the "final" version of the feature require d8 as it does now?

[kevmoo]

@iapicca – "final" is tricky to define. We'll certainly need a runtime that supports WasmGC. It's possible we may make our first release require a JS runtime as well, since we're VERY focused on the Flutter+Browser scenario. Our support will certainly evolve, though. I'd love to think we'd run on most Wasm runtimes (as long as they support GC), but that's not our focus now or in the near future.

[nex3]

I'm also extremely interested in a more portable WASM output. Requiring GC is totally understandable, but it's very important for our use-cases that we be able to integrate with as many WASM runtimes as possible—even if it means using a much lower-level API to communicate out.

[iapicca]

@kevmoo I was attempting to make a dart package to use fermyon spin,
but this is kinda of a blocker
I understand a true dart2wasm compilation is blocked by wasmGC,
I just hope that once is out we don't keep depending on flutter related approaches
kneecapping any possible "pure dart" implementation

[mit-mit]

We've now landed new support in the dart cli for invoking the dart 2 wasm compiler in the Dart and Flutter main channels:

$ dart help compile wasm
Compile Dart to a WebAssembly/WasmGC module (EXPERIMENTAL).

Usage: dart compile wasm [arguments] <dart entry point>
-h, --help              Print this usage information.
-o, --output            Write the output to <file name>.
                        This can be an absolute or relative path.
    --[no-]optimize     Optimize wasm output using Binaryen wasm-opt.
                        (defaults to on)
-v, --verbose           Print debug output during compilation
    --enable-asserts    Enable assert statements.

I have a small example of how this can be used for a Dart web app here:
https://github.com/mit-mit/sandbox/tree/main/demos/webwasm

Note that this is still within our initial focus of using WasmGC in the context of web apps (whether Flutter web apps or general ones). Over time we'd like to support more general WasmGC execution -- this issue tracks some of the additional work required for that: #53884

[liudonghua123]

It seems I can compile dart to wasm with dart 3.4.0.

Liu.D.H  dart2wasm-hello   7ms  15:37 > cat > hello.dart
void main() {
  print("Hello, World!");
}

Liu.D.H  dart2wasm-hello   17.767s  15:38 > dart hello.dart
Hello, World!

Liu.D.H  dart2wasm-hello   3.995s  15:38 > dart --version
Dart SDK version: 3.4.0 (stable) (Mon May 6 07:59:58 2024 -0700) on "windows_x64"

Liu.D.H  dart2wasm-hello   1.434s  15:38 >
Liu.D.H  dart2wasm-hello   337ms  15:39 > dart help compile wasm
Compile Dart to a WebAssembly/WasmGC module (EXPERIMENTAL).

Usage: dart compile wasm [arguments] <dart entry point>
-h, --help                  Print this usage information.
-o, --output                Write the output to <file name>.
                            This can be an absolute or relative path.
-v, --verbose               Print debug output during compilation
    --enable-asserts        Enable assert statements.
-D, --define=<key=value>    Define an environment declaration. To specify multiple declarations, use multiple options or
                            use commas to separate key-value pairs.
                            For example: dart compile wasm -Da=1,b=2 main.dart

Run "dart help" to see global options.

Liu.D.H  dart2wasm-hello   2.156s  15:40 > dart compile wasm hello.dart -o hello.wasm
*NOTE*: Compilation to WasmGC is experimental.
The support may change, or be removed, with no advance notice.

Generated wasm module 'hello.wasm', and JS init file 'hello.mjs'.

Liu.D.H  dart2wasm-hello   9.375s  15:41 >

But I can't run it with wasmer or wasmedge.

Liu.D.H  dart2wasm-hello   16ms  15:43 > node hello.mjs

Liu.D.H  dart2wasm-hello   1.027s  15:43 > wasmer hello.unopt.wasm
error: Unable to compile "hello.unopt.wasm"
╰─▶ 1: compile error

Liu.D.H  dart2wasm-hello   39ms  15:44 > wasmedge hello.wasm
[2024-05-21 15:44:21.194] [error] loading failed: integer representation too long, Code: 0x36
[2024-05-21 15:44:21.197] [error]     Bytecode offset: 0x0000000c
[2024-05-21 15:44:21.198] [error]     At AST node: function type
[2024-05-21 15:44:21.199] [error]     At AST node: type section
[2024-05-21 15:44:21.199] [error]     At AST node: module
[2024-05-21 15:44:21.200] [error]     File name: "D:\\code\\dart\\dart2wasm-hello\\hello.wasm"

Liu.D.H  dart2wasm-hello   385ms  15:44 > wasmer hello.wasm
error: Unable to compile "hello.wasm"
╰─▶ 1: compile error

Liu.D.H  dart2wasm-hello   36ms  15:44 >

[iapicca]

It seems I can compile dart to wasm with dart 3.4.0.

[...]

But I can't run it with wasmer or wasmedge.

@liudonghua123
because compile only to wasm js runtime see

• [dart2wasm] Support non-JS wasm runtimes #53884

[yanglaolee]

Wen dart to wasm runtime??

--2024.05.23

[mit-mit]

This feature is now considered done. There are some planned improvements outside the core though. For current status, please see https://dart.dev/web/wasm

[mkustermann]

For those looking for future things

• Interacting with other wasm modules: Issue 55856
• Interacting with C code compiled to wasm: Issue 46690
• Running dart2wasm-compiled code in non-JS environments: Issue 53884