Closed SilentCicero closed 3 years ago
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
@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
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.
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
Agreed, exactly what I meant above
What is the WASM support status on this lib?
What needs to be done?