- no technical benefit (but aesthetics, sure) - adds weight (payload and runtime) - might interfere with userland polly
-1 On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve <[email protected]> wrote: > 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 <[email protected]> > wrote: > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <[email protected]> > > 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 <[email protected]> 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. > > > > > > > > > >
