incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Unified phonegap javascript layer incorperating modules / plugins
Date Thu, 24 Nov 2011 18:46:53 GMT
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" <lhasson@rim.com> 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: lhasson@rim.com                       -
>- Mobile: 646-460-7066                         -
>------------------------------------------------
>"Ha ha ha... He doesn't know how to use the three seashells!" - Erwin
>
>
>-----Original Message-----
>From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of
>Brian LeRoux
>Sent: Sunday, November 20, 2011 9:22 PM
>To: callback-dev@incubator.apache.org
>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 <lhasson@rim.com> 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: lhasson@rim.com                       -
>> - Mobile: 646-460-7066                         -
>> ------------------------------------------------
>> "Ha ha ha... He doesn't know how to use the three seashells!" - Erwin
>>
>>
>> -----Original Message-----
>> From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
>>Of Brian LeRoux
>> Sent: Sunday, November 20, 2011 3:25 PM
>> To: callback-dev@incubator.apache.org
>> 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 <pmuellr@gmail.com>
>>wrote:
>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <alunny@gmail.com> 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.


Mime
View raw message