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

[Ruben Rodriguez II]

This is exactly what I was thinking when I was reading this. I have been 
building a game engine with async JS and I have run into situations 
where promises were absolutely sapping performance.

I would encourage people to look over even the faster promise libraries 
and understand just how much complexity they introduce, and how many 
'next tick'-type operations that a cascading promise chain can stimulate.

It's wonderful because of how entirely promises cover your execution 
path, making control flow silky smooth and safe. However it does come at 
a price, and any API at a 'system' level should strive to implement 
features in the most performant way by default: a callback. It'll take 1 
day to wrap your API with a promise-based API for people who would make 
that tradeoff. If you sacrifice speed first, there's no way to go back 
the other way.

We have to make sure promises aren't in any 'hot' execution path with no 
alternatives.

On 07/17/2013 07:22 PM, Silvia Pfeiffer wrote:
> On Thu, Jul 18, 2013 at 10:00 AM, Ian Hickson <ian at hixie.ch> wrote:
>> On Wed, 17 Jul 2013, Justin Novosad wrote:
>>> On Wed, Jul 17, 2013 at 6:54 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>> On Thu, 18 Jul 2013, Silvia Pfeiffer wrote:
>>>>> At the same time, I think we should follow a clear pattern for
>>>>> introducing a Promise based API, which the .create() approach would
>>>>> provide.
>>>> I don't understand what that means.
>>> I think the concern is about the case where we end up with legacy
>>> callback Factory methods that co-exist new with Promise-based flavors of
>>> the factory methods. There's no technical obstacle to having the two
>>> co-exist with the same name, it's just an overload.
> Yes, that's my concern.
>
>
>> I guess I don't understand what methods we're talking about here. Can we
>> be more concrete? I am very much in favour of not having redundant APIs,
>> not having lots of different kinds of APIs. But I'm not aware of this
>> problem existing here. We have constructors and synchronous factory
>> methods, have had for over a decade, and we're slowly adding constructors
>> where it makes sense and not adding new synchronous factory methods. But
>> in the case of ImageData, we need an asynchronous factory. This is unusual
>> in the Web; mostly we have instead returned incomplete objects. In this
>> case, the whole point of the API is to avoid this. This means we need a
>> callback mechanism; Promises are a good, non-invasive way to do this.
> 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.
>
> 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.
>
> 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. 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 just want us to be clear about the situations in which we should
> take this step and where we should avoid it.
>
> Silvia.