WASM Support about ethers-rs HOT 5 CLOSED

async in wasm is not as bad as it seems. You can convert to/from promises relatively easily. To be honest, my approach would be to ensure that the wasm32-unknown-unknown target compiles, but not provide any official wasm interface. That gives people the option to use it, with very little work up front

from ethers-rs.

@gakonst following up on this, because I just saw ethabi no_std https://github.com/darwinia-network/ethabi/tree/xavier-no-std

Would it actually be worth it to support wasm/no_std? I can't really think of a good use case...

That being said, I think we can get the problems in providers resolved for no_std

from ethers-rs.

Agreed, exactly what I meant above

from ethers-rs.

Probably hard to get it working with async-trait.

wasm-pack inside ethers-providers has this error:

Could maybe be solved by switching our async-traits to not be Send, but that would mean we can't spawn them, which is not ideal

from ethers-rs.

I don't have a great use-case in mind either, and candidly, feels like doing async stuff over wasm/ffi would be a big pain :P I think it'd be great if the crate is in a state where it compiles with no_std/wasm-pack, so that if anybody ever wanted to build things that way, they'd be able to.

from ethers-rs.