cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: WebView Promise and W3C standards
Date Wed, 10 Dec 2014 15:48:32 GMT
One specific spot in core I'd like to use it is to address this TODO in
Android's exec bridge:

https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263

The actual need is for a setImmediate polyfill, but Promise does the same
thing (with an extra object creation).

On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland <iclelland@chromium.org>
wrote:

> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > 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
> promises-based.
>
>
> >
> > 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 <bowserj@gmail.com> 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.
> > >
> >
>

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