Bit late but better than never... PhoneGap doesn't *need* modules but it *should* have them.
+1 for AMD from me. As Laurent said, we need to consider the end-user. Overhead would be. Compilation step is nice for phonegap.js but you cannot expect all scripts will be prepackaged. Consider the case where a PG app async loads libraries externally. AMD should be supported. Another argument in this thread was readability (see Gord's prototype for the readability; Brian you agree too that Gord's demo was pretty). Don't buy that commonJS is "nicer" than AMD - agree with Andrew that that is a question of style. Personally I think AMD is nicer. On 11-11-20 7:19 PM, "Laurent Hasson" <[email protected]> wrote: >Not about advocacy? I still do innerHTML and table layouts! :) It's about >how to structure the project moving forwards... and I always took this >conversation to be about (1) how to we write the framework, and (2) how >do developers use it. > - Are we expecting third-party modules to be developed in the >wild? > - If I write an app and need (a), (b) and (c), but not (d), (e), >and (f), how do I specify that? A build system is how it's done and >having modules clearly defined and dependencies managed helps doing that. > >In WebWorks, and Tim can correct me, there are potentially hundreds of >modules. To just say it's all one big file with everything in it is >something I don't understand. The fact that it's all packaged and we >don't incur bandwidth and requests to pull it all in doesn't mean it >doesn't take time to load in the browser, parse and so on. Putting it all >on the shoulders of a developer to bring it all in themselves is also >problematic. > >Maybe I am missing something here, but the way I read your messages is: >phonegap.js is fine as it is, and we don't use any modules, so why start >now? If we believe that we can control it, then maybe that's a fine >position. Otherwise, if it's going to grow, and if third-parties are able >to extend it (i.e., add new modules), and developers are going to find >themselves never needing the entire thing by far, then how do we manage >it? > >And maybe this is not a 1.x thing, maybe we'll re-architect again in 2.0 >if the need arises? Advocacy aside, I don't often come across projects >that don't need to end there, or suffer because they did this sooner >rather than later. Just my $.02. > > >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: [email protected] [mailto:[email protected]] On Behalf Of >Brian LeRoux >Sent: Sunday, November 20, 2011 9:22 PM >To: [email protected] >Subject: Re: Unified phonegap javascript layer incorperating modules / >plugins > >With respect Laurent, lets keep the conversation around our project >goals and away from library / pattern advocacy for just the moment. I >don't think we are really debating this correctly (yet) since we >aren't looking at the long view. Ultimately we don't even need a >module system for the single file that is phonegap.js which is in use >today and, indeed, we don't use one or have one. All this discussion >has been framed, I think, around authoring apps with phonegap rather >than how to author phonegap javascript itself. > >The key questions we need to answer to guide this effort: > >Are we looking to enforce a particular module semantics on 3rd party >plugin authors? (Do we have to?) Are plugins all compiled into the >phonegap.js file or are we going to see something like this: > ><script src="phonegap-exec.js"></script> ><script src="phonegap-acceleromter.js"></script> > >??? > >(And leave module loading as an exercise to the end developer...?) > > > >On Sun, Nov 20, 2011 at 5:38 PM, Laurent Hasson <[email protected]> wrote: >> Things as ambitious as PhoneGap always grow in complexity faster and >>bigger than people think. I have been in way too many projects in the >>past where "anything goes" was the order of the day in terms of macro >>structure, and then it became deeply regretted quickly. I for one don't >>see a downside to using something like AMD. And if we do want to get >>into a much more "micro-kernel" type approach for PhoneGap as a >>platform, then we'll need something. >> >> So I would put the question differently: are people so offended by the >>idea of something AMD-like? What's the downside? Verbosity? Overhead? >>Really? :) It enables tooling, dependency management, code structuring, >>plugins etc... I don't see the downside. > >> >> >> 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: [email protected] [mailto:[email protected]] On Behalf >>Of Brian LeRoux >> Sent: Sunday, November 20, 2011 3:25 PM >> To: [email protected] >> Subject: Re: Unified phonegap javascript layer incorperating modules / >>plugins >> >> Would like to draw attention back to the primary goal here: a single >> file phonegap.js that works on all the target platforms: >> >> - ios >> - android >> - blackberry >> - wp7 >> - bada >> - qt >> - browser <--- never been an explicit goal, but seems consensus here >> is that it should be given its a common practice during app dev >> >> Right now our module system is classic js: we have no module loader. >> =P We just concat our JS, always have, and leave the loading of that >> file as an exercise for the app developer using phonegap (and it >> should stay that way). >> >> Our secondary goal w/ this effort was to determine how we could move >> code out of the phonegap core and into atomic plugins. With that mind, >> a module system is could make things whole lot nicer. >> >> Do have to use a module system when we 'pluginize'? No. >> >> Here's the big question: *should* authors of plugins be forced into a >> module system? I'm thinking the answer here would be no too ---- but >> I'd love to hear everyones thoughts on that. >> >> >> On Sat, Nov 19, 2011 at 12:42 PM, Patrick Mueller <[email protected]> >>wrote: >>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <[email protected]> wrote: >>>> For PhoneGap.js, we're dealing with a finite number of modules - >>>>around >>>> twenty I'd guess, plus one for each plugin. Typically, each module >>>>only >>>> depends on phonegap/base - it's very unlikely that, say, the Camera >>>>API >>>> would depend on the Accelerometer, although there may be cases of >>>>cross >>>> dependencies. >>> >>> I take it you aren't including phonegap-plugins in that list (of 20). >>> Shouldn't they be? >> >> --------------------------------------------------------------------- >> 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. >> > >--------------------------------------------------------------------- >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.
