incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <alu...@gmail.com>
Subject Re: Unified phonegap javascript layer incorperating modules / plugins
Date Fri, 18 Nov 2011 18:23:28 GMT
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
>

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