Re: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

Le 26/04/2013 20:39, Domenic Denicola a écrit :
> I think this is a really good description of the problems and possible solutions. Unfortunately, I think you underestimate the problems.
>
>> Where should this wrapping occur? Each library can add a check+convert to all surface API. It doesn't sound that hard (library authors can jump in to say I'm crazy here).
> It's not fun, and it's pretty hard. We do this daily with Node.js libraries. Creating duplicates of existing APIs, and keeping them in sync, sucks.
This is a different problem. You're keeping in sync promises with an 
ecosystem based on callbacks, where there is a main convention (callback 
as last argument accepting (err, val)) with a lot of exceptions.
To wrap platform promises, you will need only one function. Platform 
promises come in one shape, no exception. That's much much less work 
than what you're doing with Node.js.

Note that if you want to turn existing APIs (xhr, geoloc, etc.) to 
promise-oriented APIs, additional work has to be done regardless of 
compat with other libraries.

> I would go almost as far as to say that this results in people thinking that the W3C has invented yet another sucky callback API that they can't use in a composable way with their existing code. Hooray, back where we started...
Where we diverge in opinion is that I believe it's not the platform role 
to be compatible with existing libraries. That didn't happen with jQuery 
which is thousands of times more used than promise libraries for 
instance (however good ideas from jQuery were later added to the 
platform like querySelectorAll, forEach, CSS animation, etc.)
Promise libraries have led a similar battle and I'm happy to see that 
we're discussing the inclusion of promises to the platform (in that 
sense, we're much much further than where we started). I however don't 
see why the platform should be compatible with existing code. 
Historically, when a new API was emerging to implement what authors had 
been doing, the platform API wasn't compatible with existing code and 
everyone survived.
What is so important about promises that would be enough of an incentive 
for the platform to be compatible with existing code?
Are the costs on the platform side worth it for cases where there is no 
need to be compatible with existing library (which I believe will be the 
majority and will increase as time passes since not everyone will want 
more than what the default API provides)? People who use existing 
promise libraries are not the only people concerned by the introduction 
of platform promises.

I demonstrated that the cost for existing libraries is manageable (one 
wrapping function to be called at the entrance of surface API, some 
discipline). That was enough for other libraries when other features 
were integrated to the platform.

>> Hopefully, that should work until an ecosystem (or several) built on top of platform promises emerge and new projects should be built on top of this new ecosystem.
> And, because of how the platform forced users to wrap platform promises, this seems unlikely. Why would they dedicate resources to build on top of a library that didn't feel fit to give them the time of day and integrate with them? Better to just keep using the ecosystem they already have, which doesn't cause such problems and doesn't need to be forked and rewritten for an outlier.
Some people will start using platform promises without existing 
libraries. Whether they'll want to add existing full-features libraries 
isn't sure yet. Whether they'll want to start something smaller than the 
existing promise libraries may happen.

> We are no stranger to the W3C producing crappy APIs that we bury under wrapping layers as soon as possible and never see again (see: jQuery). It would be a shame if promises in the DOM turned out to be another one of those.
More and more, people are advocating to stop using jQuery (and use the 
crappy APIs) when targeting modern browsers, because cases where jQuery 
was necessary are now often taken care of by the platform.
Additionally, work on DOM4 is bringing better APIs (thinking of 
.remove() and .on() for example). Lot of work by Anne and Ms2ger here. 
Things are improving slowly on the platform API side.

David

Received on Friday, 26 April 2013 19:31:59 UTC