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 Thu, 11 Dec 2014 01:00:30 GMT
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