incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurent Hasson <lhas...@rim.com>
Subject RE: Unified phonegap javascript layer incorperating modules / plugins
Date Fri, 18 Nov 2011 19:57:19 GMT
I think that the argument that "we have a compile step" is very thin. AMD is not all about
async loading of dependencies and scripts etc... It's also a method used to compile what's
needed, test modules etc... It's also easier at testing if the constructs remain the same
without adding the compile step. I see a lot of advantages to using something like AMD with
benefits beyond async loading which admittedly itself is a small issue for PhoneGap projects.



Thank you
------------------------------------------------
- LDH (Laurent Hasson)                         -
- Technical Director, BlackBerry Web Platform  -
- Research In Motion                           -
- Email: lhasson@rim.com                       -
- Mobile: 646-460-7066                         -
------------------------------------------------
"Ha ha ha... He doesn't know how to use the three seashells!" - Erwin


-----Original Message-----
From: Andrew Lunny [mailto:alunny@gmail.com] 
Sent: Friday, November 18, 2011 1:23 PM
To: callback-dev@incubator.apache.org
Subject: Re: Unified phonegap javascript layer incorperating modules / plugins

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
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged
material (including material protected by the solicitor-client or other applicable privileges),
or constitute non-public information. Any use of this information by anyone other than the
intended recipient is prohibited. If you have received this transmission in error, please
immediately reply to the sender and delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended recipients is not authorized
and may be unlawful.

Mime
View raw message