Re: Use of Futures/Promises in CSS Font Face APIs

On Fri, Jun 7, 2013 at 6:35 AM, Glenn Adams <glenn@skynav.com> wrote:
> During today's presentation of an alternative API for CSS FontLoader,
> reference was made to so-called "Futures" or "Promises". I would like to
> know:
>
> (1) what material improvement is afforded to this alternative when compared
> with the existing (non-Futures) API proposal? that is, what new or different
> behavior or functionality is offered by using "Futures"?

Futures/Promises encapsulate asynchrony as a first-class concept,
which allows it to be manipulated and combined in ways that are
difficult and error-prone when done with events and callbacks.  By
themselves, they're only a tiny bit better than a callback-based
interface - the only real value is that they offer a standardized,
predictable callback interface, instead of the multitude of slightly
different ways to assign callbacks today.  As more of the web begins
returning them, though, their true value comes forth - being able to
combine Promises with Promise.all, Promise.any, Promise.some, and more
combinators that libraries will inevitably produce provides a powerful
new abstraction that makes robust asynchronous programming trivial to
write.

> (2) where is the formal definition of a Futures API or functionality that
> would become a normative dependency were the "Futures" version of the
> FontLoader API adopted?

http://dom.spec.whatwg.org/#promises

> (3) what other W3C APIs under active development (or complete) makes use of
> said "Futures" APIs?

The JSON-LD API is the first spec to take the plunge.  There are
several specs with rewritten variants of their APIs in flight right
now at <https://github.com/slightlyoff/Promises/tree/master/reworked_APIs>,
and many more such as Fetch (reworked XHR) soon to be written.

As Peter said in the meeting, the TAG stands strongly behind the use
of Futures, and is pushing their use via active intervention in specs
as we speak.

> (4) does the proposed use of Futures create a dependency on a newer version
> of ECMAScript than is currently assumed by HTML (which is 5.1)?

No.  Promises are entirely polyfillable in ES5.

> (5) what is the expected impact on schedule for reaching a FPWD (or LC) if
> this alternative "Futures" approach is followed?

No impact for FPWD, aside from the slight time-cost of the minor rewrite.

~TJ

Received on Saturday, 8 June 2013 04:03:51 UTC