incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: one file to rule them all: some post 2.x thoughts
Date Wed, 06 Jun 2012 00:31:49 GMT
Jesse / Fil / Gord / Anis, I think we're all in agreement but our
suggestions are for different stages of the problem.

Today: The easiest is pre-building a monolith file with all plugins and
platform-specifics.

Tomorrow: Loading only necessary the plugins as modules (or some concat
variation).

In both: We offer a "debug" JavaScript that detects the platform and loads
the platform-specifics. For the performance hungry, they can opt into a
slimmer "prod" JavaScript that only includes a specific platform. All of
these JavaScript files can be pre-built and shipped, so the end-users do
not need to run cordova-js.

Michael

On Tue, Jun 5, 2012 at 4:40 PM, <gtanner@gmail.com> wrote:

> I have really liked the mobile-spec cordova.js file (option 2). If we have
> enough runtime information to figure out the platform (is useragent
> enough?) we could continue building platform specific files and include
> them at runtime.
>
> Could then be handled better via the cmdline tooling to only include
> platforms they care about.:
>
> cordova add ios
> cordova add blackberry
>
> ...
> Sent on the TELUS Mobility network with BlackBerry
>
> -----Original Message-----
> From: Anis KADRI <anis.kadri@gmail.com>
> Date: Tue, 5 Jun 2012 15:45:53
> To: <callback-dev@incubator.apache.org>
> Reply-To: callback-dev@incubator.apache.org
> Subject: Re: one file to rule them all: some post 2.x thoughts
>
> I vote for including the javascript generation as part of the build process
> (or separate).
> It could:
> - include the plugins that are needed (contacts, etc...).
> - use the right exec method and inludes the right  platform-specific code.
>
> Pretty much what cordova-js does right now with the ability to select what
> plugins you want.
>
> advantages:
> - smaller file that just includes what you need in terms of plugins. Faster
> load time.
> - Doesn't include plugins that are not supported by the targeted platform.
>
> I find it easier to deal with one file that has everything I need rather
> than having to include multiple files. but that is just me.
> On Tue, Jun 5, 2012 at 3:21 PM, Jesse <purplecabbage@gmail.com> wrote:
>
> > I originally envisioned something like #1, except that the individual
> APIs
> > would not be part of the master file.
> > ie. real modules, the cordova-common.js would just provide the transport,
> > and fire the correct events.  If you want to use Contacts, then you
> simply
> > add an include script tag for cdv-contacts.js
> > This would be just like any other plugin ...
> >
> > We already employ this type of modular-izing in mobile-spec in that any
> > tests you want to run must be included in the page.
> >
> > On Tue, Jun 5, 2012 at 3:10 PM, Michael Brooks <michael@michaelbrooks.ca
> > >wrote:
> >
> > > A small variation of 1)
> > >
> > > 1) Ship all platform-specific JavaScript in one file and sort it out at
> > > runtime. Provide the option to build the JavaScript for a specific
> > > platform. Basically, a debug vs production file, although most apps
> would
> > > happily use the debug in production.
> > >
> > > On Tue, Jun 5, 2012 at 2:56 PM, Brian LeRoux <brian.leroux@gmail.com>
> > > wrote:
> > >
> > > > Just had a water cooler discussion about the holy grail of having one
> > > > js file to rule them all.
> > > >
> > > > 1. platforms have differences but could it be feasible to ship all
> > > > those differences in the single file and sort out which traits to
> load
> > > > at runtime. this would certainly introduce a latency and parse hit.
> > > > this would force us to really be thinking about a protocol to
> minimize
> > > > platform differences instead of brute forcing it.
> > > >
> > > > 2. the cordova.js file could document.write a script tag including
> the
> > > > auto compiled src file (still doing different files for each platform
> > > > but the src would feel cleaner to end developers). same performance
> we
> > > > have today.
> > > >
> > > > 3. do as we do today: different files for every platform treated as a
> > > > build artifact.
> > > >
> > >
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>
>

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