Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of alunny@gmail.com designates
 209.85.212.47 as permitted sender)
MIME-Version: 1.0
Reply-To: alunny@gmail.com
In-Reply-To: 
 <CAESi+48YH4E9Labm43NpCuuug=M9_5f8rVbydKoc0RH3EFLqgQ@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>
	<CACAoQH0yVDP6wRvoNQ7CJgtZ1Ln1FnvH68-U=w2Bvsy2wY6hCA@mail.gmail.com>
	<CAESi+48YH4E9Labm43NpCuuug=M9_5f8rVbydKoc0RH3EFLqgQ@mail.gmail.com>
Date: Fri, 18 Nov 2011 10:23:28 -0800
Message-ID: 
 <CAPihERQKvLs6WKhqaAsqZMU3TGxKfuSfLpmcuPkU+ZzF-dBWUg@mail.gmail.com>
Subject: Re: Unified phonegap javascript layer incorperating modules / plugins
From: Andrew Lunny <alunny@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=00163630fdd705e5b704b2066fc2

--00163630fdd705e5b704b2066fc2
Content-Type: text/plain; charset=ISO-8859-1

On 18 November 2011 08:47, Gord Tanner <gord@tinyhippos.com> wrote:

> I would also love to see an AMD module example, in fact you can see that I
> am basically using a define statement in the build script:
> https://github.com/gtanner/phonegap/blob/master/Jakefile#L50-51


Sorry I missed that - I think you're aware of the same issues running Node
modules in the browser as I am.


> We have the luxury of having a compile step for PhoneGap which allows us to
> use the CommonJS approach and syntax without really worrying about sync vrs
> async loading or the other weird problems attempting to handle CommonJS
> modules the browser brings.
>

The concern I have is that the project becomes dependent on this compile
step - I would much prefer having working code that can always run in the
browser.

The discussion, to my mind, isn't AMD vs CommonJS/Node but an explicit
function-for-scope (explicit define) versus an implicit/generated
function-for-scope (generated define). I think scoping is one of the most
important tools a JavaScript programmer has, and hiding it away as
something that gets generated as part of a compile-step muddles the
abstraction layers, and makes programs harder to debug and reason about.

I have worked on projects that required compile-to-JS steps - not for
module loading, but for switching out mobile platform specific code - and
it became an unwieldy mess very quickly. For a project the size of
Callback, I think a runtime dependency for uncompiled code (a module
loader) is far preferable to a compile-time one.


>
> The main reason I have used CommonJS in this project and in the past is the
> ability to run unit tests in nodeJS.  This was an amazing boost in
> development time for Ripple and just felt nice to develop in.  Also it
> feels like CommonJS is the way Harmony is headed and the optimism of "it
> will all just work" is a powerful driver for my choice.
>
>
> On Fri, Nov 18, 2011 at 4:27 AM, Patrick Mueller <pmuellr@gmail.com>
> wrote:
>
> > On Fri, Nov 18, 2011 at 02:50, Brian LeRoux <b@brian.io> wrote:
> >
> > > So in short, CommonJS gives us:
> > >
> > > - better performance
> > > - better aesthetics
> > > - closer to the future
> > >
> >
> > +1 on all that
> >
> >
> > > +1 for AMD
> > >
> >
> > um, what? :-)
> >
> > Seems pretty clear that we will have to easily tolerate AMD - I'm sure
> IBM
> > folk will be using Dojo, which uses AMD-style loading.  While we could
> try
> > what Node did for a couple weeks - implement a define() function - this
> > doesn't seem feasible as the API surface for define() is quite large; eg,
> > requireJS and Dojo both support "plugins" somehow.  But requireJS has
> some
> > kind of shim they can use to run in Node, and I suspect we would want to
> > aim for that shim also working with us.  Not clear to me if Dojo has a
> > similiar shim (dunno, but doubt they could share requireJS's shim).
> >
> > Another nice things about using CommonJS/node style modules is that
> > consuming existing npm modules is a snap.  I've found this to be true for
> > some personal projects I've worked on, using modjewel, the
> CommonJS-styled
> > loader I use for weinre.
> >
> > --
> > Patrick Mueller
> > http://muellerware.org
> >
>
>
>
> --
> Gord Tanner
> Senior Developer / Code Poet
> tinyHippos Inc.
> @tinyhippos
>

--00163630fdd705e5b704b2066fc2--