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 >
