The problem with futures vs promises

core
1

Here is one big problem I have with meteor’s use of futures: they work on the server, but not the client. This seems pretty inconsistent with the complete design of Meteor: it’s supposed to be a complete stack but acts inconsistently on client and server because there are no futures.

This makes it easier to use promises on both client and server, which are just wraps around futures on the server.

So my question: why don’t we have client futures? As in, something that acts like futures on the client.

2

Well, futures are not possible on the client, and that’s indeed an annoyance.
However, it doesn’t really matter to much, since you’re usually not dealing with futures directly and most of the async stuff happens in sync on the server, so the API you use is still the same.

Promises is another API, which kind of ruins the synchronous-looking code.

Es7 async may change this, an interesting talk from on this: http://benjamn.github.io/goto2015-talk/#/1

3

They can still “simulate” futures on the client using promises, and it would be more uniform. I think they should try doing that

4

How exactly can you simulate futures with promises?