Promise support

[Pauan]

^ Title

[koute]

This is still very much an open problem!

We can either have our own wrapper, or (preferably?) we can maybe base ourselves on common futures crate if possible.

I haven't yet got around to binding any Promise-using APIs so I haven't explored this problem space. If you're interested in helping then you could whip up some proof-of-concepts how this would work and research how we'd want to bind Promise APIs.

[CryZe]

@koute Considering there's a lot of requests to get Promises in, can we take just the generic futures part (so no http / timeout / interval) from the stdweb-io crate and move them into stdweb so Promises can be properly used in Rust? That's just a few lines of code then with not really a lot of magic involved.

I could whip up an experimental PR to explore how this would look like.

[koute]

@CryZe Right, I was just about to mentoin your stdweb-io. Yes, maybe we could! If you're feeling up to it feel free to create a PR and then we'll think about it in more detail.

[Pauan]

@koute My opinion is that stdweb should provide basic low-level Promise support (i.e. support for the then method with closures), and not much else. Other crates can provide a nice slick Rust-y API on top of the low-level stuff in stdweb.

In other words, I think stdweb should try to stick as close as possible to the JavaScript API (within reason), serving as a solid foundation that other crates can then build on top of. We already see that with the virtual_view_dom crate.

[koute]

@Pauan Yep. That's also what I think. But sometimes the original JS API doesn't translate very well to Rust in its unmodified form (like, for example, addEventListener), so you need to take at least some liberties with it.

As I've said, I haven't explored the problem space yet at all so I simply can't tell you what I think would be best to do here. (A lot of stuff in stdweb looked very different originally, and only got up to this point after a few iterations on the design.) If someone tries to take a stab at the problem and puts out a minimal PR it will be easier to figure out the way to go here.

[CryZe]

I think there should definitely be a 1:1 Promise API as much as possible. Assuming we can have a 1:1 Promise API, we can then build an optional tiny wrapper on top that translates a Promise into a Rust future so we gain Rust's async await syntax and all of the futures crate's future combinators. So we have all of the JavaScript APIs available, but also full on compatibility with the Rust world.

It may make sense to keep that tiny wrapper in a different crate, but it's so tiny that I think it may make sense to be part of stdweb, just because it gives you so much compatibility with the eco system, additional async await syntax, a ton of combinators, ... all with very little effort.

[koute]

@CryZe That sounds reasonable to me. I'm definitely fine with having a built in "compatibility" wrapper like that to interact with the rest of the Rust ecosystem. We already have some support for serde purely because it's an integral part of Rust's ecosystem; I don't see why futures would be any different.