[whatwg] Proposal: createImageBitmap should return a "Promise" instead of using a callback

[Damon Oehlman]

I think all I would say with regards to implementing promises is that it's
too early.  Primarily for these reasons:

- The developer community (primarily JS) is still debating the semantics of
promises.  There is the promises a+ spec (
http://promises-aplus.github.io/promises-spec/) which has reasonably wide
agreement, but there have been some conjecture to that implementation.
Primarily about using lessons learned in other programming languages to
implement a more robust version of promises.

- Using promises for some interaction with browser APIs and not others will
likely lead to confusion.  While I think a lot of developers bemoan
callback functions,  it is a very clear flag that a method is asynchronous
and thus requires particular treatment.

>From my perspective it seems pragmatic to leave the decision around
promises vs callbacks to a JS implementor and have the pure browser
implementation stick with the callbacks for now.  I think a promise based
implementation could be unpopular either way with developers using it -
either they will prefer their promises to behave in a way different to the
native browser implementation, or they'll prefer pure callbacks.

I do concede that calling foo().then(success, failure) is not much
different to simply calling foo(success, failure) as you pointed out.  If
this can be implemented without any performance penalty then this is
probably fine for those of us happy with using callbacks.

I'll have a bit more of a hunt around online for discussion around W3C
Promise implementation - hopefully some of the folks with significant
experience in the JS space have already weighed in.   I won't comment on
that, but there will be some risks around it being out of step with is
being used out there already.

Cheers,
Damon.




On Thu, Jul 18, 2013 at 10:39 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
> >
> > We have the same issues with WebRTC, which already has a callback based
> > API, but there is a suggestion to replace/augment with a Promise based
> > API, so I just wanted to understand the motivation, potential
> > complications and implications.
>
> WebRTC's constructor is synchronous, no? There are callbacks, sure; there
> are callbacks all over the place in the Web platform. Promises themselves
> use callbacks. I don't understand the relevance to createImageBitmap().
>
>
> > One issue is the change in API paradigm that we use. People have got
> > used to wrapping the callback API with a Promise style API when they
> > need it. Now they have to do both: wrap the browser API for a Promise
> > style API and wrap it for a callback style API.
>
> You don't have to wrap it for a callback style API. It _is_ a callback-
> style API. The only difference is the order of arguments.
>
> Instead of:
>
>    foo(success, failure);
>
> ...you write:
>
>    foo().then(success, failure);
>
> It's hardly cumbersome.
>
>
> > It may well be that Promises are the right way to go for
> > createImageBitmap(), but we are blazing a new trail here and need to be
> > careful about the implications.
>
> As far as I can tell, the only implications are that you can later use the
> Promise utility methods to combine things together, so you don't have to
> manage the callbacks yourself. This seems like a win.
>
>
> > For example, here is an interesting discussion thread with a statement
> > that node.js originally used Promises, but moved away from them for
> > several reasons, not least because they created a 20% performance
> > degradation with v8:
> >
> https://github.com/gladiusjs/gladius-core/issues/127#issuecomment-5212272
>
> I think you're massively misreading that parenthetical.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
Damon Oehlman
http://github.com/DamonOehlman