cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: Introduction
Date Tue, 07 Jul 2015 18:16:50 GMT
exactly so and by all means please feel free to use that, bluebird, rsvp,
q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]

though I suggest one limits the scope to the other 200+ libraries claiming
A+ support! [2]



On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <> wrote:

> I'd just like to mention that jQuery has promises built-in as the
> $.Deferred object. It's not quite the same as the official Promises spec,
> but can be used similarly in most cases.
> On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <> wrote:
>> We experimented with Promise polyfills and had nothing but trouble. I'd
>> like to preface by saying: lets not get into a theory war. Some people like
>> promises (fine) and some do not (also fine). My stance is that we should
>> leave that choice up to our end users.
>> Lets throw some facts out to colour things.
>> 1. Promises are a spec that will land in browsers natively [1]
>> 2. Promises as a concept have MANY polyfill implementations
>> 3. The polyfill landscape is largely divergent and implement different
>> flavors of the concept
>> Since we implement a User Agent we *could* polyfill to spec. As a plugin.
>> (Jake's is probably best [2]) I'd be in favor of this and making that THE
>> plugin dep for companion plugins that require Promises. The problem with
>> this is #3. If we have a window.Promise it could be clobbered by a user
>> that is not super aware of how things are composed under the hood. If it
>> *could* happen guess what: it will. Some frameworks even force the idea of
>> Promises that may not be totally on spec. Older jQuery and Ember come to
>> mind.
>> The other way to solve this problem is patience. This is the path I am most
>> in favor of. Lets wait out the native implementation to land in the various
>> webviews and at such time we can start using those.
>> Plugins really should wrap device and operating system API's (in my
>> opinion) and we should leave library code for the user land to figure out.
>> The Promise API *is a library* until such time as it has been implemented
>> into the language runtimes natively (and not just speculatively
>> standardized). Ok I guess faltered into the theory war part there. ;)
>> [1]
>> [2]
>> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <> wrote:
>>  Hey Paul,
>>>  Welcome to Cordova! I've looked at your changes on github and have some
>>>  early feedback.
>>>  1) As per spec you return a Promise on battery.js but to my knowledge we
>>>  don't have a fallback for ES6 Promises on platforms that don't support it
>>>  yet. I would like to know what other committers think about this problem.
>>>  2) I think the old API and the new API can co-exist for a while before we
>>>  deprecate and remove the old one. I see that the new spec uses a different
>>>  method name so we should be fine here.
>>>  Thanks,
>>>  Murat
>>>  -----Original Message-----
>>>  From: Paul Contat []
>>>  Sent: Wednesday, July 1, 2015 12:38 AM
>>>  To:
>>>  Subject: Introduction
>>>  Hello everyone,
>>>  My name is Paul Contat, and I'm an engineering student and currently doing
>>>  an internship at W3C focusing on aligning cordova API with W3C ones where
>>>  applicable, as part of the HTML5Apps EU project (
>>>  )
>>>  For my internship, I’m planning to contribute to the cordova project,
>>>  starting by the BatteryStatus API (
>>> if it’s possible.
>>>  I've just signed the ICLA, created an account on Apache JIRA so I’m ready
>>>  to start and submitted my first pull request:
>>>  I’m looking forward to feedback on whether I’m on the right path for
>>>  updating the Battery plugin API; I’m in particular interested to understand
>>>  if and how the current API should be deprecated once we get to a stage
>>>  where the new API is deemed in a good enough shape.
>>>  Best regards,
>>>  Paul
> --
> Tyler Freeman
> CTO, Tappur
> Sent from mobile

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message