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: [email protected] - - Mobile: 646-460-7066 - ------------------------------------------------ "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin -----Original Message----- From: Andrew Lunny [mailto:[email protected]] Sent: Friday, November 18, 2011 1:23 PM To: [email protected] Subject: Re: Unified phonegap javascript layer incorperating modules / plugins On 18 November 2011 08:47, Gord Tanner <[email protected]> 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 <[email protected]> > wrote: > > > On Fri, Nov 18, 2011 at 02:50, Brian LeRoux <[email protected]> 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.
