cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Suggestion - pluginLoader
Date Fri, 21 Jun 2013 13:12:42 GMT
Hi Jonathan,

First, thanks for a well-written proposal. At least for me, I'm not really
sure that there is enough of a problem with the current approach that would
justify changing it. That said, business is always an issue, and bumping
your thread was the right thing to do :)

For Android and iOS, the large majority of plugins require native code in
order to be useful, so I don't think that having plugin JS be dynamically
seems that useful without being able to dynamically load the native parts
of it.

You said that you're serving your app via HTTP. I think your best bet would
be to concat all of your plugin JS together would be by far your biggest
performance boost rather than try to selectively load them.

Until very recently, Cordova's module system didn't involve a loader at
all, and required that all modules be defined ahead of time. Now, we
actually do load plugin .js files during start-up, but still not on-demand.
So, in my mind we really have two things:
1. A registry
2. A boot-up process.

To be clear - is it that you want to change the registry part, or is it
just that you want to have plugin .js loaded on-demand? Are you concerned
about the native side of the plugins?

One thing I think maybe we should add is the ability to disable the
start-up plugin_loader.js logic for when people want to package the .js
themselves.





On Fri, Jun 21, 2013 at 8:30 AM, J Prince <princej.ws01@hotmail.co.uk>wrote:

> So it's been about a week now and I haven't really had any feedback on
> this.
> https://github.com/jxp/cordova.pluginLoader
>  I'm not sure if this means;
>
> a) Everyone is too busy
> b) Everyone assumed someone else would respond
> c) No-one is that interested in plugin javascript definitions
> d) You've had similar discussions before and don't want to start THAT again
>
>
> > From: princej.ws01@hotmail.co.uk
> > To: dev@cordova.apache.org
> > Subject: RE: Suggestion - pluginLoader
> > Date: Tue, 18 Jun 2013 16:55:19 +0100
> >
> > I have (briefly) looked at Harmony loaders before but that is a spec for
> a future javascript language version.
> > I have found a module loader that I wish to use (require.js).
> >
> > My point is that the current suggested module definition for cordova
> plugins INCLUDES a loader implementation.
> >
> > I am suggesting that the loader implementation be removed from the
> plugin to a new method cordova.pluginLoader
> > This would make the plugins cleaner (as they would only describe their
> own behaviour) and it would also allow cordova or app developers to
> change/customize the loader implementation as needed.
> >
> > My suggested approach would result in plugins that could be loaded in
> multiple different ways including (but not limited to); "classic"
> window.plugins, cordova.define and require.js
> >
> >
> > > -----Original Message-----
> > > From: J Prince [mailto:princej.ws01@hotmail.co.uk]
> > > Sent: Monday, June 17, 2013 7:27 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Suggestion - pluginLoader
> > >
> > > There are a few main reasons.
> > >
> > > 1. The app I am working on is an Enterprise app. We are designing the
> app as a Cordova shell that re-directs to all the html content. This means
> that we have to dynamically load a different cordova.js (depending on
> platform) following the redirect.
> > > So we are actually unable to do anything other than dynamically load
> plugins once the platform specific cordova.js is loaded
> > >
> > > 2. Some of the plugins will be used incredibly rarely. It doesn't seem
> necessary to always load plugins until they are needed.
> > >
> > > 3. We are building with a single page architecture so don't want to
> end up with lots of script includes in the index.html page.
> > > The define/require pattern feels much cleaner and better
> compartmentalized.
> > > Our main page currently has 2 script includes: require.js and jqmobi.
> > >
> > >
> > >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message