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 16:42:10 GMT
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

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. ;)


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

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