Tracking issue for web support

[Desdaemon]

This issue tracks upcoming web support for the library, most of the progress is done on the wasm_bindgen wasm_workers branch.

• Merge web shim for RawSendPort and store_dart_post_cobject to upstream Use MessagePort
• Separate native and web implementations
• Merge changes from Refactor to beautify the implementation #338
• Write marshaller macro
• Refactor WASM into a target system
• Tree-shake unused js-sys bindings
• Write web shim for Int64List and Uint64List (BigInt64List may remain unsupported)
• Make StreamSink Send
• Write supporting documentation
• Write integration tests

Also see #295

[Desdaemon]

Some implementation notes:

• I wasn't able to make use of web_ffi due to lack of support for structs, so wire structs are implemented by plain JS objects. As suggested by @fzyzcjy, arrays work fine.
• The JS bridge would definitely be synchronous and therefore devastating for performance, unless we find a way to route them through Web Workers. We might be able to use wasm-futures-executor for wasm32 targets, but questions remain about the overhead of spawning threads in WASM. Web Workers work, and are quite amazing!

[fzyzcjy]

Great work and I am looking forward to it!

I wasn't able to make use of web_ffi due to lack of support for structs, so wire structs are implemented by plain JS objects.

No problem. In JS people use objects very frequently.
Btw another possibility, if you like, may be to use arrays. Just as what I did before sending data from Rust to Dart, I encapsulate them in arrays. For example, class A {int a; String b; double c;} becomes [value_of_a, value_of_b, value_of_c] on the wire.

The JS bridge would definitely be synchronous and therefore devastating for performance, unless we find a way to route them through Web Workers. We might be able to use wasm-futures-executor for wasm32 targets, but questions remain about the overhead of spawning threads in WASM.

Interesting...

Firstly, I see Rust can use threads happily with wasm https://web.dev/webassembly-threads/. So I guess at the pure Rust side it should be no problem?
Secondly, in the original frb implementation, Dart call Rust synchronously and Rust code immediately returns. Then later when Rust (in another thread) finally finish heavy job, it will use a SendPort to send the data back. So I guess web does not have an alternative for such "rust send data to dart at any time" mechanism? Can we find one - if so then we seem to have async support

[Desdaemon]

Btw another possibility, if you like, may be to use arrays. Just as what I did before sending data from Rust to Dart, I encapsulate them in arrays

I might try this. The only reason I didn't initially is that I wanted to make use of wasm_bindgen a bit more, but doing it this way may cut down some proc macro calls.

Firstly, I see Rust can use threads happily with wasm https://web.dev/webassembly-threads/. So I guess at the pure Rust side it should be no problem?

Yeah, I'm under the impression that Rust WASM threads right now are completely in userland, so any solution will be highly specific to a certain set of libraries.

So I guess web does not have an alternative for such "rust send data to dart at any time" mechanism? Can we find one - if so then we seem to have async support

There's SharedWorker, which is similar in spirit but the API is a bit different. This actually gave me a good idea, but it will be a while before I can implement it.

[Desdaemon]

I think comlink can help clean up the code considerably, also helps my sanity as well.

[fzyzcjy]

I might try this. The only reason I didn't initially is that I wanted to make use of wasm_bindgen a bit more, but doing it this way may cut down some proc macro calls.

I agree. Both approaches seem good.

There's SharedWorker, which is similar in spirit but the API is a bit different. This actually gave me a good idea, but it will be a while before I can implement it.
I think comlink can help clean up the code considerably, also helps my sanity as well.

Sounds good. I guess we cannot use comlink directly since that is a JS lib. But maybe we can port it (or rewrite it) in Dart, and since it is only 1KB in size, it should not be too hard. Or maybe we can let Dart call JS.

[fzyzcjy]

Multi-platform: Android, iOS, Windows, Linux, MacOS (Web coming soon)

The above line is added to README

[fzyzcjy]

Btw curious how is this going on? I am trying to find some time working on this. (I re-encounter this when editing the doc)

[Desdaemon]

I've been busy and not actively using this library, so progress might be a bit slow.

[fzyzcjy]

Take your time! Just want to know the progress such that when I start working on implementing this I do not reinvent the wheel

[fzyzcjy]

Btw may I make https://github.com/Desdaemon/flutter_rust_bridge/tree/wasm_bindgen a draft PR? Since draft PRs can be more easily reviewed and read.

And I noticed it may need some refactoration b/c of my refactoration yesterday... Sorry I did not notice there is this branch since I only checked the PR page. I can rebase for it.

[Desdaemon]

I took a quick look at that branch, it seems that there are quite a lot of conflicts now...

[fzyzcjy]

I took a quick look at that branch, it seems that there are quite a lot of conflicts now...

No problem. I can refactor code of that branch as well if you like. Indeed the big refactoration of this repo I have done a few days ago is not something magic: The core thing is to move some code to separate files.

[tojocky]

Any ETA when this will be available in the main branch?

[fzyzcjy]

@tojocky You are welcome to contribute to the PR! (@Desdaemon has been working on this and has already made some progress)

@Desdaemon Maybe we can make it a draft PR, such that it is easier to track the progress and we will not accidentally merge it without finished?

[Desdaemon]

@tojocky @fzyzcjy I have created a PR to cover the basics of WASM codegen, but needless to say there are still many things to do. I'll split this issue into smaller ones once I can isolate the key areas for this contribution.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mztink]

what's the status of web support?

[Desdaemon]

Still ongoing, no ETA yet sorry.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SecondFlight]

Shoo, stale bot

[Desdaemon]

First successful release run:

Right now, flutter run doesn't work since buffer-sharing needs some HTTP headers to work.

[fzyzcjy]

Looks great! Cannot wait to see the PR and get it merged :)

[BppleMan]

That's great. this is a great project.
I am starting a new project and hope to see pr soon.

[fzyzcjy]

@BppleMan hope to see pr soon.

Already merged :)

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.