cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Blanc <scm.bl...@gmail.com>
Subject Re: WebView Promise and W3C standards
Date Thu, 11 Dec 2014 14:49:05 GMT
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 <mmocny@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 <agrieve@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 <mmocny@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 <
> mmocny@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 <purplecabbage@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 <
> > > > agrieve@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
<
> > > > > > 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