cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: WebView Promise and W3C standards
Date Wed, 10 Dec 2014 15:15:19 GMT
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.

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

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