Just to let you know we have been using a promises polyfill plugin for some time now : https://github.com/vstirbu/PromisesPlugin
On Thu, Dec 11, 2014 at 3:38 AM, Michal Mocny <mmo...@chromium.org> wrote: > Jesse: yes, that could work. By setting your polyfill to <runs/> you'll be > sure it is available after pluginsready (and thus deviceready). For > plugins that use Promises during bootstrap, which is unlikely to be common, > the explicit require() on the polyfill is still an option. > > Regarding your Native injection suggestion: how early on in the boot > process can we do this? i.e. do you modify the startPage to inject this > before loading cordova.js, or do you do it in response to an exec bridge > call, making the timing about equivalent to the js polyfill? > > -Michal > > On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux <b...@brian.io> wrote: > > > we should move browserify to main and drop that insane concat code > > > > its not heavyweight at all. it creates a hash in iife with deps mapped > > in…as to why dep mgmt is better than concatenating…I don't think we need > to > > waste our time talking about that! > > > > On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve <agri...@chromium.org> > > wrote: > > > > > There's something implemented behind a --browserify flag, but not sure > > what > > > it does. > > > > > > Totally in favour of having CLI / plugman concatenate plugin JS with > > > cordova.js, but not convinced that browserify is the right tool for > this, > > > as it seems quite heavy-weight for just concatenating things. If > someone > > is > > > going to resume work on it, would love to hear a summary of what > problems > > > it's solving (if more than concatenation), and why something more > > > light-weight wouldn't be better. > > > > > > On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny <mmo...@chromium.org> > > wrote: > > > > > > > We haven't worked on it, also curious. Anis, perhaps? > > > > > > > > On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > > > > > def think we should support those specs in our great and fabled api > > > > > audit…had not considered the load order issue > > > > > > > > > > not insurmountable and probably should be a feature/fix for the > > plugin > > > > > loader load order …but also sort of scary… reminds me of script > tags > > > hell > > > > > > > > > > on that note: we need to make browserify thing first class. whats > the > > > > hold > > > > > up on that front? > > > > > > > > > > On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny < > mmo...@chromium.org> > > > > > wrote: > > > > > > > > > > > Do we prefer to invent new cordova-specific apis, or prefer to > > match > > > > > > standard browser apis? When there is no browser spec to match > then > > > > > design > > > > > > comes down to aesthetics and personal preference (as you say). > But > > > > often > > > > > > there is an existing browser spec, and then it comes down to > match > > or > > > > > > fork. I'm in the camp of preferring to match, and was under the > > > > > assumption > > > > > > others here were too. > > > > > > > > > > > > Given the upcoming specs mentioned earlier (sockets, file, > > > filesystem, > > > > > > permissions, service worker, fetch), seems that fighting the > > adoption > > > > of > > > > > > promises in core apis implies opposing the adoption of modern web > > > > specs. > > > > > > e.g. I'm assuming Andrew was referring to > > > > > > http://www.w3.org/TR/battery-status/, since matching that spec > > > *would* > > > > > > require promises. > > > > > > > > > > > > > > > > > > Now, as I understand, you are not saying you are opposed to > > adoption > > > of > > > > > > promises in Cordova, but that you are simply against the > inclusion > > > of a > > > > > > polyfill directly inside cordova-js. I think that a > > > promises-polyfill > > > > > > plugin alternative has some technical downsides [1], but they > seem > > > not > > > > so > > > > > > insurmountable that we shouldn't just get passed this debate and > do > > > > that. > > > > > > > > > > > > In my opinion, we should prefer to create a common plugin (at > least > > > > until > > > > > > browserify), since I really hope we don't tell devs to just > include > > > > their > > > > > > own polyfill with each plugin. > > > > > > > > > > > > [1]: > > > > > > - Can't rely on a polyfill plugin for cordova-js itself. There > > are a > > > > few > > > > > > places where that may have been useful. > > > > > > - We don't currently load plugins in an order that respects > plugin > > > > > > dependencies, so every plugin relying on promises-polyfill will > > have > > > to > > > > > > require() it at runtime before using and forgetting to do so > > > > > > may-or-may-not lead to an error. Maybe we just fix this in our > > > plugin > > > > > > loader. > > > > > > - It seems odd that window.Promise will exist depending on which > > > > plugins > > > > > > you have installed. While this technically isn't different than > > with > > > > any > > > > > > plugin modifying global symbols, it seems odd-er when applied to > a > > > > > > dependant platform feature. > > > > > > > > > > > > -Michal > > > > > > > > > > > > On Wed, Dec 10, 2014 at 1:56 PM, Jesse <purplecabb...@gmail.com> > > > > wrote: > > > > > > > > > > > > > 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 <b...@brian.io> > > 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 < > > > > agri...@chromium.org > > > > > > > > > > > > > > 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 < > > > > > > iclell...@chromium.org > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve < > > > > > > > agri...@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 < > > > > bows...@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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
