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

[Tab Atkins Jr.]

On Jul 17, 2013 9:00 PM, "Ruben Rodriguez II" <whatwg at therealcha0s.net>
wrote:
>
>
> On 07/17/2013 07:51 PM, Tab Atkins Jr. wrote:
>>
>> On Jul 17, 2013 8:40 PM, "Ruben Rodriguez II"
>>> 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.
>>
>> Forcing people to wrap with their own code is just a way of saying "lol,
>> we're not actually doing that".
>
> There's Q's deferred.makeNodeResolver()...

I'm not sure what relevance this has. Whether you write it yourself or use
an (inconveniently long-named) library to do the wrapping, it's still not
first-class; it's still highly inconvenient compared to the language doing
it properly from the start.

>> Callbacks are no faster than promises,
>
> This isn't starting well...
>
>> because to maintain consistent
>> semantics, they have to delay across ticks anyway.
>
> It's not about 'delaying across ticks', it's about how many extra tick
delays resolving a composed promise chain is causing. Every time you do
promise.then(resolver), you're (invisibly) creating yet another promise, in
yet another tick. These things add up, again I would encourage you to study
some promise libraries. We can't credibly ascribe a zero cost to promises.

I think you didn't quite realize my point. If you chain multiple promises,
it's likely because *you're chaining multiple async operations together*.
It doesn't matter what syntax you use, this will involve the total
operation being spread across multiple ticks, at least one per operation.
Callbacks don't change anything, because it's the fundamental asynchrony
that's causing any speed problems.

If you're just chaining because of convenience, where multiple parts of the
chain return non-promise values, then any slowdown you experience is a
solvable issue - just combine some of the operations. Promises may make it
easier to be less efficient here (you wouldn't willingly manually create
callback-taking functions when chaining together sync operations), but
that's a basic and common price of accepting higher levels of abstraction.

~TJ