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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
