aantron/promise

Repromise vs Future

malthe opened this issue · 2 comments

malthe commented

How does this library compare to Future, a "Js.Promise alternative [...] written in ReasonML" – ?

aantron commented

The main difference is:

  • Repromise objects, in the vast majority of cases, are the familiar JS promises under the hood. This means that a Repromise containing an int, is implemented as a JS promise containing a JS number.

Repromise just takes care of one corner case in JS promises, that makes JS promises not type-safe out of the box. Repromises are type-safe. See this explanation if you'd like to know the details.

In contrast, future is an alternative implementation of promises.


This has several consequences:

  • In the vast majority of cases (see here), existing JS libraries that take or return JS promises, already take and return Repromises for free. So, when writing a binding for a JS library, you don't have to convert JS promises to Repromises and vice versa. You just declare that the JS library's functions take and return Repromises.

    By contrast, with an alternative implementation, you have to call helpers to convert between JS promises and custom promises around each FFI call, probably building that conversion into the binding you are writing.

  • Tooling from the JS community built for JS promises works with Repromises for free. If you inspect a Repromise, it will look exactly like a JS promise (except in that one corner case, of course, but even in that case, the representation is simple and predictable).

  • The Repromise compiled JS code is quite small (~1K compressed last I checked), because Repromise basically reuses JS promises for free, and only replaces a couple of troublesome methods with type-safe ones.


Of course, Repromise also has a second pure-Reason implementation, implementing promises from the ground up. However, Repromise currently doesn't use this for JS. It's used for providing the same Repromise API on native, i.e. it implements type-safe JS-like promises when targeting native code.


I think that's most of it, but perhaps I forgot something :)

  • 👍3
malthe commented

Thanks!