cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Re: WebView Promise and W3C standards
Date Wed, 10 Dec 2014 15:35:34 GMT
On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <>

> userland means that plugins won't be able to use them unless every plugin
> also includes a copy of the polyfill within it.
> Looking at our core APIs, seems maybe it's just battery-status that will
> require it. Should we have battery-status include the polyfill within it? I
> hope not. I'd hate to get to where several plugins in my app all bundle the
> same polyfill.

I believe that Mozilla's new File API, which I think we're planning to
implement, and which should be as core as File is now, is also heavily

> If we move to having the entire cordova.js built using browserify where
> every plugin gets to contribute to the JS that goes into it - yes I can see
> this solving this use-case as well. But that also seems to me like a much
> larger and much more controversial change.
> Whether you are for or against promises - they are already here. They
> exists natively on most latest mobile webviews, and every vendor has
> committed to adding them. And they are being used in *most* new specs that
> I've seen (sockets, filesystem, permissions, service worker, fetch)
> Are there any concrete downsides to putting Promises polyfill right in
> cordova-js?

As long as the promise doesn't clobber the native implementation, if it
exists, and we can remove it completely from platforms when they don't need
it anymore, it seems to me like a small price for having this available to
all platforms. (Other opinions vary, I'm sure, though)

> On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser <> wrote:
> > +1 to userland. I see other approaches causing more problems.
> >
> > BTW: The only time I use promises is when the platform explicitly
> requires
> > it, and right now that's just MozillaView.  While I think it looks
> awesome,
> > I view Promises as a luxury right now and not a standard feature as of
> yet.
> >
> > I also really wish specs wouldn't rely on code that only exists on the
> very
> > latest browsers. It just makes life harder on people who have to
> implement
> > stuff.
> >

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