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 <mich...@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.ler...@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
