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 18:54:51 GMT
Let's start a new thread for browserify.

Jesse - def. like the idea of injecting polyfills when they are not there
but are required. In practice though, I think it ends up pretty much the
same anyways:
- On start-up you need to feature-detect Promise via JS
- If it's not there, you need to inject it.

Whether the injection occurs via the native side shoving it in, or by
cordova.js require()'ing a module is a matter of whether we check in
es6-promise.js into each platform separately, or into cordova-js.


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