Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of alunny@gmail.com designates
 209.85.220.175 as permitted sender)
MIME-Version: 1.0
Reply-To: alunny@gmail.com
In-Reply-To: 
 <CADVgkyN1p23rRvwKiENZcVxwP-t-vMafYVoLSToEXLF+Ab5WeA@mail.gmail.com>
References: 
 <CAESi+48mA=zxBVX1S+4dw=wPqibHRcKOoqGFNzf4CfrtALbnCg@mail.gmail.com>
	<CADq=2H7ppfFMu3fqpGmTiu2oEtRLZ6J_MftYDUCAjD9X1GCo7Q@mail.gmail.com>
	<CAPihERT8EumrayuBZSu-ef1+4FLWsxR5GaUb_iXvip_O6ui+Ng@mail.gmail.com>
	<CADVgkyN1p23rRvwKiENZcVxwP-t-vMafYVoLSToEXLF+Ab5WeA@mail.gmail.com>
Date: Fri, 18 Nov 2011 09:59:30 -0800
Message-ID: 
 <CAPihERRacZOt0Sof879JkS-ZD5OMGVJUV4bZXhc-00XeTzHayg@mail.gmail.com>
Subject: Re: Unified phonegap javascript layer incorperating modules / plugins
From: Andrew Lunny <alunny@gmail.com>
To: Brian LeRoux <b@brian.io>
Cc: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf300fb0394d60a204b20619ef

--20cf300fb0394d60a204b20619ef
Content-Type: text/plain; charset=ISO-8859-1

On 17 November 2011 23:50, Brian LeRoux <b@brian.io> wrote:

> The

other issue, for our purposes, is some (tho not all) AMD style
> compilers will end up w/ a larger footprint b/c of all the extra
> ceremony. Not to mention more closure ceremony. We'd actually hurt
> performance.
>

This is an assertion without any evidence that (a) performance would be
worse or (b) the performance impact would significantly impact apps.
There's no reason why AMD can't be used as an organization tool during
development and compiled to a single file for production.


>
> From the aesthetics side, AMD is harder to read/write than a CommonJS
> exports style.
>

AMD uses immediately-invoked functions, as the vast majority of JavaScript
libraries do. There's no more "closure ceremony" than in the XUI source.
But it's a point of opinion.


>
> From a future proofing perspective Harmony Modules will support
> CommonJS. Not that a rewrite is beyond our capacity but its nice to
> know that once the lang supports modules our code should 'just work'.
>

No, Harmony will have new syntax for modules:
http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples and
http://wiki.ecmascript.org/doku.php?id=harmony:modules


> I doubt that'll be the case but, hey, we can hope. I do know James
> Burke, author of RequireJS AMD lib, is working towards a shim for
> Harmony Modules but his work isn't complete yet.
>

James also wrote a post a couple of days ago defending AMD as still the
best pragmatic choice for client-side devs:
http://tagneto.blogspot.com/2011/11/why-not-amd.html


> So in short, CommonJS gives us:
>

Node is not CommonJS - it has a module system based on an early draft of
the CommonJS work, that is not common to any other JavaScript environment.


> - better performance
> - better aesthetics
> - closer to the future
>
> "closer to the future" is factually incorrect. The other two are
unqualified assertions.


> +1 for AMD
>
> (But pls do a prototype anyhow b/c I think it would be interesting for
> us to contrast.)
>
>
> On Fri, Nov 18, 2011 at 7:59 AM, Andrew Lunny <alunny@gmail.com> wrote:
> > What's the reasoning behind developing this as a Node module?
> >
> > Node's great but I'm not sure if it's the best suited tool for this job -
> > is it worth considering using AMD modules with existing script
> > loaders/preprocessors? The JavaScript layer of PhoneGap/Callback is a
> > client-side application, so I'd be in favour of going with the grain of
> > existing client-side module solutions (requirejs, based on dojo modules,
> > being the most prominent one).
> >
> > (hope to have some time to protoype something based on Gord's work, with
> > AMD instead, in the next couple of weeks, but I'm curious what the other
> > devs' thoughts are)
> >
> > On 17 November 2011 22:47, Dave Johnson <dave.c.johnson@gmail.com>
> wrote:
> >
> >> Awesome. Looking forward to working on this!
> >>
> >> -dave
> >> On Nov 17, 2011 1:13 PM, "Gord Tanner" <gtanner@gmail.com> wrote:
> >>
> >> > Hello,
> >> >
> >> > I have put together a quick prototype to iron out some of the design
> >> > choices I think would really help phonegap to get to a point where we
> >> have
> >> > one common javascript layer for all platforms.
> >> >
> >> > Source can be found here:
> >> > https://github.com/gtanner/phonegap
> >> >
> >> > the HACKING file outlines key areas to focus on:
> >> > https://github.com/gtanner/phonegap/blob/master/HACKING
> >> >
> >> > Key points:
> >> >
> >> > - All API definitions in phonegap should be plugins / modules.
> >> > - In additional to being able to require in submodules, the existing
> >> > phonegap APIs should still be injected.
> >> > - There is one javascript project that is common across all platforms.
> >> > -- Should allow for platform specific overrides
> >> > -- Should allow for 3rd party modules to easily be included and used.
> >> >
> >> >
> >> > Currently this has only been tested on Ripple (ripple.tinyhippos.com)
> >> in a
> >> > special prototype branch I wrote to emulate the native layer a little
> >> > closer.  If you want to run it instructions can be found in the readme
> >> > file:
> >> > https://github.com/gtanner/phonegap/blob/master/README.md
> >> >
> >> >
> >> > The plan is to further define this architecture and rapidly build out
> >> more
> >> > support next week and get it running on a few of the platforms.
> >> >
> >> > Cheers!
> >> >
> >> > -----
> >> > Gord Tanner
> >> > Code  Poet
> >> > Research In Motion
> >> >
> >>
> >
>

--20cf300fb0394d60a204b20619ef--