Why does battery-status 'require' promises? I agree that promises are here to stay, but I am unclear why it would be a good idea to go and change/rewrite/break our apis to use them?
Most of the windows plugins use promises all over the place, the entire async windows js api is promise based, but this has zero impact on what our core-api looks like to a user. The same should apply to any plugin that wants to depend on promises, just depend on a promise plugin, which may or may not add polyfil code to the dom. @purplecabbage risingj.com On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux <[email protected]> wrote: > - 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. > > > > > > > > > > > > > > >
