You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Gord Tanner <gt...@gmail.com> on 2011/11/17 21:27:04 UTC
Unified phonegap javascript layer incorperating modules / plugins
Hello,
I have put together a quick prototype to iron out some of the design
choices I think would really help phonegap to get to a point where we have
one common javascript layer for all platforms.
Source can be found here:
https://github.com/gtanner/phonegap
the HACKING file outlines key areas to focus on:
https://github.com/gtanner/phonegap/blob/master/HACKING
Key points:
- All API definitions in phonegap should be plugins / modules.
- In additional to being able to require in submodules, the existing
phonegap APIs should still be injected.
- There is one javascript project that is common across all platforms.
-- Should allow for platform specific overrides
-- Should allow for 3rd party modules to easily be included and used.
Currently this has only been tested on Ripple (ripple.tinyhippos.com) in a
special prototype branch I wrote to emulate the native layer a little
closer. If you want to run it instructions can be found in the readme file:
https://github.com/gtanner/phonegap/blob/master/README.md
The plan is to further define this architecture and rapidly build out more
support next week and get it running on a few of the platforms.
Cheers!
-----
Gord Tanner
Code Poet
Research In Motion
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Jesse MacFadyen <pu...@gmail.com>.
+1 for all Andrew has said.
Having a build tool to gen individual device js and having unified js
that runs on all devices are competing goals, at some level.
The core pieces I think we need to address are:
a) a well defined interface to the runtime PhoneGap object ( or PG )
b) agreement on how each device API functions ( ie. is the
accelerometer watch managed in native or js? )
c) clean cross device JavaScript implementations for each API
Trying to solve all our issues at once, IMHO will be virtually
impossible given the number of people that would have agree. I also
believe we can all agree that the above are steps in the right
direction.
Discussions of how this all gets munged together into an optimized
runtime can happen later, or can be based on what we discover along
the way.
Cheers,
Jesse
Sent from my iPhone5
On 2011-11-18, at 10:23 AM, Andrew Lunny <al...@gmail.com> wrote:
> On 18 November 2011 08:47, Gord Tanner <go...@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 <pm...@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
>>
RE: Unified phonegap javascript layer incorperating modules /
plugins
Posted by Laurent Hasson <lh...@rim.com>.
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 <go...@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 <pm...@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.
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Andrew Lunny <al...@gmail.com>.
On 19 November 2011 04:26, Patrick Mueller <pm...@gmail.com> wrote:
> On Fri, Nov 18, 2011 at 13:23, Andrew Lunny <al...@gmail.com> wrote:
> > 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 don't ever remember seeing anyone in Node-land complaining about the
> hidden boilerplate. The boilerplate is defined here:
> https://github.com/joyent/node/blob/master/src/node.js#L522 . Can you
> provide some links to conversations concerning this with Node?
>
That file loads the core node.js module (http, file, etc) into the node
binary at compile time. It doesn't affect userland code that is required at
runtime - this is the code you're looking for:
https://github.com/joyent/node/blob/master/lib/module.js#L362-433
which ultimately resolves to
https://github.com/joyent/node/blob/master/src/node_script.cc#L276-279
There's no boilerplate added to user code, the user code is executed
through either runInThisContext or runInNewContext, each of which is tied
to a handle to V8.
Node has a very clear execution model which we're unable to match, because
of the constraints of our environment.
> Rather, I think Nodesters probably *enjoy* not having to write the
> boilerplate, and knowing they get a "free" closure-per-file without
> any ceremony. I know I do. This experience matches other programming
> languages I've dealt with over the years, which provide some amount of
> "file private" capabilities (eg, static in C).
Node is an independent execution environment tied directly to a single
Virtual Machine. PhoneGap/Callback targets multiple execution environments,
each of which has the constraints of a browser environment with its own
scoping rules, most of which are using different VMs, that we do not have
direct access to. If we had `instance_eval` and `class_eval` then we could
make the code as pretty as Rails, but we don't and we won't.
A digression on your digression, but this thread's already off track: there
is a long-running discussion on the node mailing list about coroutines, or
libraries that would implement coroutine functionality by transforming code
at build-time. While a vocal minority is in favor of such an approach (see
the node-fibers and streamlinejs) for concision and perceived readability,
the core team and most experienced node developers reject these libraries
as obscuring the execution model for no substantial increase in
expressiveness. I wonder if there's a lesson there :)
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Patrick Mueller <pm...@gmail.com>.
On Fri, Nov 18, 2011 at 13:23, Andrew Lunny <al...@gmail.com> wrote:
> 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 don't ever remember seeing anyone in Node-land complaining about the
hidden boilerplate. The boilerplate is defined here:
https://github.com/joyent/node/blob/master/src/node.js#L522 . Can you
provide some links to conversations concerning this with Node?
Rather, I think Nodesters probably *enjoy* not having to write the
boilerplate, and knowing they get a "free" closure-per-file without
any ceremony. I know I do. This experience matches other programming
languages I've dealt with over the years, which provide some amount of
"file private" capabilities (eg, static in C).
--
Patrick Mueller
http://muellerware.org
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Andrew Lunny <al...@gmail.com>.
On 18 November 2011 08:47, Gord Tanner <go...@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 <pm...@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
>
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Gord Tanner <go...@tinyhippos.com>.
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
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 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 <pm...@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
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Patrick Mueller <pm...@gmail.com>.
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
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Patrick Mueller <pm...@gmail.com>.
On Sun, Nov 20, 2011 at 15:24, Brian LeRoux <b...@brian.io> wrote:
> Here's the big question: *should* authors of plugins be forced into a
> module system?
Yes. None of the module systems add that much overhead that it will
become somehow "expensive" to make a plugin modulized. Trying to deal
with plugins, some of which are modules, and some of which are wads of
js, is likely to be not much fun.
--
Patrick Mueller
http://muellerware.org
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Viras <vi...@users.sourceforge.net>.
I didn't say it doesn't make sense (in fact, as you pointed out, it
makes a lot of sense in some cases). I just wanted to point out that it
might not be allowed.
Loading external execution code is explicitly not allowed by Apples App
Guidelines. That's all I wanted to note!
Am 25.11.2011 16:37, schrieb Brian LeRoux:
> Actually, async resource loading has lots of use cases even in a
> compiled app. Best one to illustrate would be an app that includes
> Google Maps but that isn't the primary function. No sense in loading
> it up front but if the user requests that view then loading those JS
> assets on demand makes sense --- and having an async mechanism to do
> it does too.
>
>
> On Thu, Nov 24, 2011 at 10:56 PM, Viras <vi...@users.sourceforge.net> wrote:
>> Just as a side note: async loading of externally libraries shouldn't be
>> a top target, especially as this is for example not allowed on iOS and I
>> guess it isn't on other platforms as well.
>>
>> PhoneGap/Callback/Cordova is mainly targeting embedded devices in a
>> closed execution environment - this is not a webpage per se. I would
>> just like to keep that in mind when doing design decisions.
>> (that's just my opinion, please correct me if I'm wrong with that).
>>
>> Best,
>> Wolfgang
>>
>> Am 24.11.2011 19:46, schrieb Filip Maj:
>>> 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" <lh...@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 <lh...@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 <pm...@gmail.com>
>>>>> wrote:
>>>>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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.
>>>
>>>
>>
>> --
>> GOFG - Get On Fat Guy
>> http://www.gofg.at/ - powered by PhoneGap
>>
>
--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by PhoneGap
Re: Unified phonegap javascript layer incorperating modules /
plugins
Posted by Filip Maj <fi...@adobe.com>.
Hey everyone,
We have a working version of Gord's prototype up in a repo on github here:
http://github.com/callback/callback-js
See the README for details on how it works and how to contribute.
Gord and I got this running on a BlackBerry today. I think Jesse is making
progress with WP7. I'm going to try to get it rocking on Android today as
well.
Still lots to do for this project. Currently we are using a version of
require.js that supports CommonJS modules. Down the road I would like to
see a mirror implementation in AMD so we can compare the two.
Fork away and send pull requests !
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Brian LeRoux <b...@brian.io>.
Actually, async resource loading has lots of use cases even in a
compiled app. Best one to illustrate would be an app that includes
Google Maps but that isn't the primary function. No sense in loading
it up front but if the user requests that view then loading those JS
assets on demand makes sense --- and having an async mechanism to do
it does too.
On Thu, Nov 24, 2011 at 10:56 PM, Viras <vi...@users.sourceforge.net> wrote:
> Just as a side note: async loading of externally libraries shouldn't be
> a top target, especially as this is for example not allowed on iOS and I
> guess it isn't on other platforms as well.
>
> PhoneGap/Callback/Cordova is mainly targeting embedded devices in a
> closed execution environment - this is not a webpage per se. I would
> just like to keep that in mind when doing design decisions.
> (that's just my opinion, please correct me if I'm wrong with that).
>
> Best,
> Wolfgang
>
> Am 24.11.2011 19:46, schrieb Filip Maj:
>> 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" <lh...@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 <lh...@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 <pm...@gmail.com>
>>>> wrote:
>>>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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.
>>
>>
>
> --
> GOFG - Get On Fat Guy
> http://www.gofg.at/ - powered by PhoneGap
>
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Viras <vi...@users.sourceforge.net>.
Just as a side note: async loading of externally libraries shouldn't be
a top target, especially as this is for example not allowed on iOS and I
guess it isn't on other platforms as well.
PhoneGap/Callback/Cordova is mainly targeting embedded devices in a
closed execution environment - this is not a webpage per se. I would
just like to keep that in mind when doing design decisions.
(that's just my opinion, please correct me if I'm wrong with that).
Best,
Wolfgang
Am 24.11.2011 19:46, schrieb Filip Maj:
> 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" <lh...@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 <lh...@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 <pm...@gmail.com>
>>> wrote:
>>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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.
>
>
--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by PhoneGap
Re: Unified phonegap javascript layer incorperating modules /
plugins
Posted by Filip Maj <fi...@adobe.com>.
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" <lh...@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 <lh...@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 <pm...@gmail.com>
>>wrote:
>>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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.
RE: Unified phonegap javascript layer incorperating modules /
plugins
Posted by Laurent Hasson <lh...@rim.com>.
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 <lh...@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 <pm...@gmail.com> wrote:
>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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.
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Brian LeRoux <b...@brian.io>.
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 <lh...@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 <pm...@gmail.com> wrote:
>> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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.
>
RE: Unified phonegap javascript layer incorperating modules /
plugins
Posted by Laurent Hasson <lh...@rim.com>.
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 <pm...@gmail.com> wrote:
> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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.
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Brian LeRoux <b...@brian.io>.
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 <pm...@gmail.com> wrote:
> On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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?
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Patrick Mueller <pm...@gmail.com>.
On Sat, Nov 19, 2011 at 14:21, Andrew Lunny <al...@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?
I see things like Accelerometer, Compass, etc as "built-in" modules
... modules that we provide with the base. Plugins are just modules
that aren't provided by the base. Just as users add and remove
plugins from their projects, we should provide a way to add and remove
the "built-in" modules. Eg, we could continue to ship a wad of .js
that has all the built-in modules, but a user should be able to easily
remove one or all of these as well. And then add them back later,
somehow.
If we ignore user code for the moment, how often do you figure people
are going to be rebuilding their "core" (== base phone gap bits +
"built in" modules they've selected + external modules ("plugins")
they've selected), where that "built core" is what users know today as
"phonegap-x.y.z.js"?
--
Patrick Mueller
http://muellerware.org
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Andrew Lunny <al...@gmail.com>.
>
>
> As a con-AMD folk, all I really have to point to for the
> Node/CommonJS-style modules is the Node documentation/implementation.
> modjewel (used by weinre) pretty much follows CommonJS standards, but
> I think Node's module semantics are nicer. The path search mechanism
> based on convention(node_modules, package.json, et al) I think works
> out better than having to deal with CommonJS path configuration
> (require.paths, or whatever).
>
Paths are of minor importance - as Brian pointed out on Twitter, we're
ultimately talking about one file.
> The reason I'm asking for AMD specs is because I don't know what the
> expectation is beyond implementing a define() function. For instance,
> what are the specs for the require() function which you can request be
> passed into your module factory? Likewise, what is the shape of
> "module"?
>
> When using define(), would we be forced to pass the module id as the
> first parameter, or alternatively, be forced NOT to pass the module
> id, or does it work either way? If you imagine collecting AMD modules
> to put in a single concatenated script for production, you obviously
> need the module id's in there. Does the runtime or some tool rewrite
> my modules and add the module id if I don't use one?
> Is it ok to not use the pre-reqs bit? I actually prefer a literal
> require() invocation in my code, and don't feel like spending my time
> keeping pre-req names in an array in a function parameter, and pre-req
> variables in parameters lined up. It's never been clear to me if
> *not* using pre-reqs is ok. Seemed like the story was if you didn't
> use pre-reqs, the module would be scanned for require() statements.
> Will we support that?
>
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.
What I would like is:
* each module is its own function. I think everyone agrees with this -
Gord's code compiles to this; the only difference is whether the module
author writes "function ..." or a tool/compiler does
* each module needs to have an id. We're ultimately going to be in a single
file - putting the id right in the module definition seems like the best
place. Again, Gord's code does this when it de-sugars to require.define
* all dependencies specified in the `define` call, and no requires inline
in the module. I would like every module-function to be passed arguments,
execute its code, and return a value. No compile-time or run-time
transformations, no function.toString weirdness. This seems like the most
controversial point.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Patrick Mueller <pm...@gmail.com>.
On Fri, Nov 18, 2011 at 12:59, Andrew Lunny <al...@gmail.com> wrote:
>...
> James also wrote a post a couple of days ago defending AMD as still the
> best pragmatic choice for client-side devs:
> http://tagneto.blogspot.com/2011/11/why-not-amd.html
>...
Would some of the pro-AMD folks point to AMD specifications that we
would implement to, and point to AMD implementations that we might
reuse?
The AMD spec, as near as I can tell, is here:
https://github.com/amdjs/amdjs-api/wiki/AMD . Is there something
else?
As a con-AMD folk, all I really have to point to for the
Node/CommonJS-style modules is the Node documentation/implementation.
modjewel (used by weinre) pretty much follows CommonJS standards, but
I think Node's module semantics are nicer. The path search mechanism
based on convention(node_modules, package.json, et al) I think works
out better than having to deal with CommonJS path configuration
(require.paths, or whatever).
The reason I'm asking for AMD specs is because I don't know what the
expectation is beyond implementing a define() function. For instance,
what are the specs for the require() function which you can request be
passed into your module factory? Likewise, what is the shape of
"module"?
When using define(), would we be forced to pass the module id as the
first parameter, or alternatively, be forced NOT to pass the module
id, or does it work either way? If you imagine collecting AMD modules
to put in a single concatenated script for production, you obviously
need the module id's in there. Does the runtime or some tool rewrite
my modules and add the module id if I don't use one?
Is it ok to not use the pre-reqs bit? I actually prefer a literal
require() invocation in my code, and don't feel like spending my time
keeping pre-req names in an array in a function parameter, and pre-req
variables in parameters lined up. It's never been clear to me if
*not* using pre-reqs is ok. Seemed like the story was if you didn't
use pre-reqs, the module would be scanned for require() statements.
Will we support that?
--
Patrick Mueller
http://muellerware.org
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Viras <vi...@users.sourceforge.net>.
Well don't get me wrong, I only wanted to point out that I don't think
it would be good for callback to favor one javascript framework (this
also includes jQuery) - I'm not implying that you are planning to do so :).
Am 19.11.2011 14:34, schrieb Patrick Mueller:
> On Sat, Nov 19, 2011 at 06:09, Viras <vi...@users.sourceforge.net> wrote:
>> However I would avoid sticking to a syntax of a popular framework. E.g.
>> I'm a fan of jquery and I'm using jquery.mobile for my app with great
>> success, however if you now force me to stick to a commonJS like syntax
>> for callback it will be quite confusing.
>
> Existing, non-modular JavaScript shouldn't be a problem to handle for
> any of the module systems. What syntax do you think we'd be forcing
> on people to use jquery mobile, for example?
>
> In fact, I don't think we'd ever want to "auto-modulize" any existing
> JS file. You'll continue to use jquery mobile by adding a <script
> src=> for it in your .html files, or however you currently do it.
>
> That said, jQuery has nascent support for some flavor of AMD -
> https://github.com/jquery/jquery/blob/master/src/exports.js
>
> Last note, some folks write JavaScript such that it can be used in
> multiple environments; underscore can be used in a browser by just
> <script src>'ing it, used in CommonJS, and it appears now to support
> AMD:
>
> https://github.com/documentcloud/underscore/blob/master/underscore.js#L51
>
--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by PhoneGap
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Patrick Mueller <pm...@gmail.com>.
On Sat, Nov 19, 2011 at 06:09, Viras <vi...@users.sourceforge.net> wrote:
> However I would avoid sticking to a syntax of a popular framework. E.g.
> I'm a fan of jquery and I'm using jquery.mobile for my app with great
> success, however if you now force me to stick to a commonJS like syntax
> for callback it will be quite confusing.
Existing, non-modular JavaScript shouldn't be a problem to handle for
any of the module systems. What syntax do you think we'd be forcing
on people to use jquery mobile, for example?
In fact, I don't think we'd ever want to "auto-modulize" any existing
JS file. You'll continue to use jquery mobile by adding a <script
src=> for it in your .html files, or however you currently do it.
That said, jQuery has nascent support for some flavor of AMD -
https://github.com/jquery/jquery/blob/master/src/exports.js
Last note, some folks write JavaScript such that it can be used in
multiple environments; underscore can be used in a browser by just
<script src>'ing it, used in CommonJS, and it appears now to support
AMD:
https://github.com/documentcloud/underscore/blob/master/underscore.js#L51
--
Patrick Mueller
http://muellerware.org
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Viras <vi...@users.sourceforge.net>.
I'm really looking forward to this. I've done some work on a single
javascript for cross-platform and just some platform specific
implementations (like the PG.exec function).
However I would avoid sticking to a syntax of a popular framework. E.g.
I'm a fan of jquery and I'm using jquery.mobile for my app with great
success, however if you now force me to stick to a commonJS like syntax
for callback it will be quite confusing.
I would try to stick to "standard" (whatever that is) javascript calls
like callback does right now - this doesn't set any preferences for any
additonal JS frameworks which might be used together with callback.
In addition my vote goes to handling as much of the API logic as
possible on the JS side (of course platform independence is still top
priority).
I did something like that for my rewrite of the callback-qt code. The
geolocation code contains the whole timeout code on the javascript side,
which reduced the native code to a minimum and will make porting
callback to new platforms way more easy.
https://github.com/Viras-/phonegap-qt/blob/master/www/js/geolocation.js
I'm using the same base javascript for both my versions of phonegap-qt &
phonegap-bada!
Just my thoughts....
Best,
Viras
Am 19.11.2011 06:35, schrieb Brian LeRoux:
> As a quick update, I pinged brendan and harmony separates the
> definition of modules (into a commonjs inspired syntax) and the
> loading of modules into a new api called module loader api. So,
> basically, these things are not mutually exclusive.
>
> Which is actually how Gord did things ... perhaps our loader can be
> AMD satisfying the technical requirements outlined here and the
> definition can be in the CommonJS style. For those doing browser dev
> or that want worse performance they can use the Loader. For those
> building phonegap apps (into a phone) the compiler does the job.
>
> There are a bunch of google-able articles about how to do this (really
> good one from sitepen).
>
>
> On Sat, Nov 19, 2011 at 6:28 AM, Brian LeRoux <b...@brian.io> wrote:
>>>> - better performance
>>>> - better aesthetics
>>>> - closer to the future
>>>>
>>> "closer to the future" is factually incorrect. The other two are unqualified
>>> assertions.
>>
>>
>> Wow, nothing like nuanced debate on semantics pretending to be
>> academic. You say I don't qualify my statements but provide no
>> evidence of your own. Look forward to seeing the code. I agree its
>> *possible* to write something that has less footprint, and said as
>> much, but the semantics of AMD are read/writ in a more involved
>> fashion for the end developer than a simple exports object.
>>
>> As to the Harmony compat, that was from a brendan eich talk (that we
>> both attended btw). It was a goal which maybe changed but thats not
>> the point. The syntax for CommonJS is closer than the ceremony we see
>> in AMD which was why I said there will be changes. I suppose that
>> wasn't clear enough.
>>
>> Anyhow, none of this matters until we see the proposal in code form.
>> Right now we're debating aesthetics and developer ergonomics which
>> always sounds abjectly religious.
>>
>
--
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by PhoneGap
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Patrick Mueller <pm...@gmail.com>.
On Sat, Nov 19, 2011 at 00:35, Brian LeRoux <b...@brian.io> wrote:
> Which is actually how Gord did things ... perhaps our loader can be
> AMD satisfying the technical requirements outlined here and the
> definition can be in the CommonJS style. For those doing browser dev
> or that want worse performance they can use the Loader. For those
> building phonegap apps (into a phone) the compiler does the job.
AMD started life as CommonJS Transport/C -
http://wiki.commonjs.org/wiki/Modules/Transport/C ; in CommonJS lingo,
a Transport is a bit of runtime, along with some boilerplate you wrap
around your module, so that you can actually get all this stuff to
work.
For modjewel (CommonJS module system I use for weinre), I had
originally implemented Transport/D, but more recent versions use an
subset of AMD as my boilerplate.
So, it's pretty obvious that AMD and Node/CommonJS-styled modules can
co-exist, in some sense.
The big trick, for a build tool, is figuring out whether or not you
have to "wrap" a .js file or not, before concatenating it to the built
wad.
--
Patrick Mueller
http://muellerware.org
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Brian LeRoux <b...@brian.io>.
As a quick update, I pinged brendan and harmony separates the
definition of modules (into a commonjs inspired syntax) and the
loading of modules into a new api called module loader api. So,
basically, these things are not mutually exclusive.
Which is actually how Gord did things ... perhaps our loader can be
AMD satisfying the technical requirements outlined here and the
definition can be in the CommonJS style. For those doing browser dev
or that want worse performance they can use the Loader. For those
building phonegap apps (into a phone) the compiler does the job.
There are a bunch of google-able articles about how to do this (really
good one from sitepen).
On Sat, Nov 19, 2011 at 6:28 AM, Brian LeRoux <b...@brian.io> wrote:
>>> - better performance
>>> - better aesthetics
>>> - closer to the future
>>>
>> "closer to the future" is factually incorrect. The other two are unqualified
>> assertions.
>
>
> Wow, nothing like nuanced debate on semantics pretending to be
> academic. You say I don't qualify my statements but provide no
> evidence of your own. Look forward to seeing the code. I agree its
> *possible* to write something that has less footprint, and said as
> much, but the semantics of AMD are read/writ in a more involved
> fashion for the end developer than a simple exports object.
>
> As to the Harmony compat, that was from a brendan eich talk (that we
> both attended btw). It was a goal which maybe changed but thats not
> the point. The syntax for CommonJS is closer than the ceremony we see
> in AMD which was why I said there will be changes. I suppose that
> wasn't clear enough.
>
> Anyhow, none of this matters until we see the proposal in code form.
> Right now we're debating aesthetics and developer ergonomics which
> always sounds abjectly religious.
>
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Brian LeRoux <b...@brian.io>.
>> - better performance
>> - better aesthetics
>> - closer to the future
>>
> "closer to the future" is factually incorrect. The other two are unqualified
> assertions.
Wow, nothing like nuanced debate on semantics pretending to be
academic. You say I don't qualify my statements but provide no
evidence of your own. Look forward to seeing the code. I agree its
*possible* to write something that has less footprint, and said as
much, but the semantics of AMD are read/writ in a more involved
fashion for the end developer than a simple exports object.
As to the Harmony compat, that was from a brendan eich talk (that we
both attended btw). It was a goal which maybe changed but thats not
the point. The syntax for CommonJS is closer than the ceremony we see
in AMD which was why I said there will be changes. I suppose that
wasn't clear enough.
Anyhow, none of this matters until we see the proposal in code form.
Right now we're debating aesthetics and developer ergonomics which
always sounds abjectly religious.
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Andrew Lunny <al...@gmail.com>.
On 17 November 2011 23:50, Brian LeRoux <b...@brian.io> wrote:
> The
other issue, for our purposes, is some (tho not all) AMD style
> compilers will end up w/ a larger footprint b/c of all the extra
> ceremony. Not to mention more closure ceremony. We'd actually hurt
> performance.
>
This is an assertion without any evidence that (a) performance would be
worse or (b) the performance impact would significantly impact apps.
There's no reason why AMD can't be used as an organization tool during
development and compiled to a single file for production.
>
> From the aesthetics side, AMD is harder to read/write than a CommonJS
> exports style.
>
AMD uses immediately-invoked functions, as the vast majority of JavaScript
libraries do. There's no more "closure ceremony" than in the XUI source.
But it's a point of opinion.
>
> From a future proofing perspective Harmony Modules will support
> CommonJS. Not that a rewrite is beyond our capacity but its nice to
> know that once the lang supports modules our code should 'just work'.
>
No, Harmony will have new syntax for modules:
http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples and
http://wiki.ecmascript.org/doku.php?id=harmony:modules
> I doubt that'll be the case but, hey, we can hope. I do know James
> Burke, author of RequireJS AMD lib, is working towards a shim for
> Harmony Modules but his work isn't complete yet.
>
James also wrote a post a couple of days ago defending AMD as still the
best pragmatic choice for client-side devs:
http://tagneto.blogspot.com/2011/11/why-not-amd.html
> So in short, CommonJS gives us:
>
Node is not CommonJS - it has a module system based on an early draft of
the CommonJS work, that is not common to any other JavaScript environment.
> - better performance
> - better aesthetics
> - closer to the future
>
> "closer to the future" is factually incorrect. The other two are
unqualified assertions.
> +1 for AMD
>
> (But pls do a prototype anyhow b/c I think it would be interesting for
> us to contrast.)
>
>
> On Fri, Nov 18, 2011 at 7:59 AM, Andrew Lunny <al...@gmail.com> wrote:
> > What's the reasoning behind developing this as a Node module?
> >
> > Node's great but I'm not sure if it's the best suited tool for this job -
> > is it worth considering using AMD modules with existing script
> > loaders/preprocessors? The JavaScript layer of PhoneGap/Callback is a
> > client-side application, so I'd be in favour of going with the grain of
> > existing client-side module solutions (requirejs, based on dojo modules,
> > being the most prominent one).
> >
> > (hope to have some time to protoype something based on Gord's work, with
> > AMD instead, in the next couple of weeks, but I'm curious what the other
> > devs' thoughts are)
> >
> > On 17 November 2011 22:47, Dave Johnson <da...@gmail.com>
> wrote:
> >
> >> Awesome. Looking forward to working on this!
> >>
> >> -dave
> >> On Nov 17, 2011 1:13 PM, "Gord Tanner" <gt...@gmail.com> wrote:
> >>
> >> > Hello,
> >> >
> >> > I have put together a quick prototype to iron out some of the design
> >> > choices I think would really help phonegap to get to a point where we
> >> have
> >> > one common javascript layer for all platforms.
> >> >
> >> > Source can be found here:
> >> > https://github.com/gtanner/phonegap
> >> >
> >> > the HACKING file outlines key areas to focus on:
> >> > https://github.com/gtanner/phonegap/blob/master/HACKING
> >> >
> >> > Key points:
> >> >
> >> > - All API definitions in phonegap should be plugins / modules.
> >> > - In additional to being able to require in submodules, the existing
> >> > phonegap APIs should still be injected.
> >> > - There is one javascript project that is common across all platforms.
> >> > -- Should allow for platform specific overrides
> >> > -- Should allow for 3rd party modules to easily be included and used.
> >> >
> >> >
> >> > Currently this has only been tested on Ripple (ripple.tinyhippos.com)
> >> in a
> >> > special prototype branch I wrote to emulate the native layer a little
> >> > closer. If you want to run it instructions can be found in the readme
> >> > file:
> >> > https://github.com/gtanner/phonegap/blob/master/README.md
> >> >
> >> >
> >> > The plan is to further define this architecture and rapidly build out
> >> more
> >> > support next week and get it running on a few of the platforms.
> >> >
> >> > Cheers!
> >> >
> >> > -----
> >> > Gord Tanner
> >> > Code Poet
> >> > Research In Motion
> >> >
> >>
> >
>
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Brian LeRoux <b...@brian.io>.
This is a good discussion to have.
No technical benefit for an AMD approach since we have a compile step.
Arguably all JS apps should have a compile step and, shouldn't take an
AMD approach at all unless they are doing dynamic code loading. The
other issue, for our purposes, is some (tho not all) AMD style
compilers will end up w/ a larger footprint b/c of all the extra
ceremony. Not to mention more closure ceremony. We'd actually hurt
performance.
>From the aesthetics side, AMD is harder to read/write than a CommonJS
exports style.
>From a future proofing perspective Harmony Modules will support
CommonJS. Not that a rewrite is beyond our capacity but its nice to
know that once the lang supports modules our code should 'just work'.
I doubt that'll be the case but, hey, we can hope. I do know James
Burke, author of RequireJS AMD lib, is working towards a shim for
Harmony Modules but his work isn't complete yet.
So in short, CommonJS gives us:
- better performance
- better aesthetics
- closer to the future
+1 for AMD
(But pls do a prototype anyhow b/c I think it would be interesting for
us to contrast.)
On Fri, Nov 18, 2011 at 7:59 AM, Andrew Lunny <al...@gmail.com> wrote:
> What's the reasoning behind developing this as a Node module?
>
> Node's great but I'm not sure if it's the best suited tool for this job -
> is it worth considering using AMD modules with existing script
> loaders/preprocessors? The JavaScript layer of PhoneGap/Callback is a
> client-side application, so I'd be in favour of going with the grain of
> existing client-side module solutions (requirejs, based on dojo modules,
> being the most prominent one).
>
> (hope to have some time to protoype something based on Gord's work, with
> AMD instead, in the next couple of weeks, but I'm curious what the other
> devs' thoughts are)
>
> On 17 November 2011 22:47, Dave Johnson <da...@gmail.com> wrote:
>
>> Awesome. Looking forward to working on this!
>>
>> -dave
>> On Nov 17, 2011 1:13 PM, "Gord Tanner" <gt...@gmail.com> wrote:
>>
>> > Hello,
>> >
>> > I have put together a quick prototype to iron out some of the design
>> > choices I think would really help phonegap to get to a point where we
>> have
>> > one common javascript layer for all platforms.
>> >
>> > Source can be found here:
>> > https://github.com/gtanner/phonegap
>> >
>> > the HACKING file outlines key areas to focus on:
>> > https://github.com/gtanner/phonegap/blob/master/HACKING
>> >
>> > Key points:
>> >
>> > - All API definitions in phonegap should be plugins / modules.
>> > - In additional to being able to require in submodules, the existing
>> > phonegap APIs should still be injected.
>> > - There is one javascript project that is common across all platforms.
>> > -- Should allow for platform specific overrides
>> > -- Should allow for 3rd party modules to easily be included and used.
>> >
>> >
>> > Currently this has only been tested on Ripple (ripple.tinyhippos.com)
>> in a
>> > special prototype branch I wrote to emulate the native layer a little
>> > closer. If you want to run it instructions can be found in the readme
>> > file:
>> > https://github.com/gtanner/phonegap/blob/master/README.md
>> >
>> >
>> > The plan is to further define this architecture and rapidly build out
>> more
>> > support next week and get it running on a few of the platforms.
>> >
>> > Cheers!
>> >
>> > -----
>> > Gord Tanner
>> > Code Poet
>> > Research In Motion
>> >
>>
>
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Andrew Lunny <al...@gmail.com>.
What's the reasoning behind developing this as a Node module?
Node's great but I'm not sure if it's the best suited tool for this job -
is it worth considering using AMD modules with existing script
loaders/preprocessors? The JavaScript layer of PhoneGap/Callback is a
client-side application, so I'd be in favour of going with the grain of
existing client-side module solutions (requirejs, based on dojo modules,
being the most prominent one).
(hope to have some time to protoype something based on Gord's work, with
AMD instead, in the next couple of weeks, but I'm curious what the other
devs' thoughts are)
On 17 November 2011 22:47, Dave Johnson <da...@gmail.com> wrote:
> Awesome. Looking forward to working on this!
>
> -dave
> On Nov 17, 2011 1:13 PM, "Gord Tanner" <gt...@gmail.com> wrote:
>
> > Hello,
> >
> > I have put together a quick prototype to iron out some of the design
> > choices I think would really help phonegap to get to a point where we
> have
> > one common javascript layer for all platforms.
> >
> > Source can be found here:
> > https://github.com/gtanner/phonegap
> >
> > the HACKING file outlines key areas to focus on:
> > https://github.com/gtanner/phonegap/blob/master/HACKING
> >
> > Key points:
> >
> > - All API definitions in phonegap should be plugins / modules.
> > - In additional to being able to require in submodules, the existing
> > phonegap APIs should still be injected.
> > - There is one javascript project that is common across all platforms.
> > -- Should allow for platform specific overrides
> > -- Should allow for 3rd party modules to easily be included and used.
> >
> >
> > Currently this has only been tested on Ripple (ripple.tinyhippos.com)
> in a
> > special prototype branch I wrote to emulate the native layer a little
> > closer. If you want to run it instructions can be found in the readme
> > file:
> > https://github.com/gtanner/phonegap/blob/master/README.md
> >
> >
> > The plan is to further define this architecture and rapidly build out
> more
> > support next week and get it running on a few of the platforms.
> >
> > Cheers!
> >
> > -----
> > Gord Tanner
> > Code Poet
> > Research In Motion
> >
>
Re: Unified phonegap javascript layer incorperating modules / plugins
Posted by Dave Johnson <da...@gmail.com>.
Awesome. Looking forward to working on this!
-dave
On Nov 17, 2011 1:13 PM, "Gord Tanner" <gt...@gmail.com> wrote:
> Hello,
>
> I have put together a quick prototype to iron out some of the design
> choices I think would really help phonegap to get to a point where we have
> one common javascript layer for all platforms.
>
> Source can be found here:
> https://github.com/gtanner/phonegap
>
> the HACKING file outlines key areas to focus on:
> https://github.com/gtanner/phonegap/blob/master/HACKING
>
> Key points:
>
> - All API definitions in phonegap should be plugins / modules.
> - In additional to being able to require in submodules, the existing
> phonegap APIs should still be injected.
> - There is one javascript project that is common across all platforms.
> -- Should allow for platform specific overrides
> -- Should allow for 3rd party modules to easily be included and used.
>
>
> Currently this has only been tested on Ripple (ripple.tinyhippos.com) in a
> special prototype branch I wrote to emulate the native layer a little
> closer. If you want to run it instructions can be found in the readme
> file:
> https://github.com/gtanner/phonegap/blob/master/README.md
>
>
> The plan is to further define this architecture and rapidly build out more
> support next week and get it running on a few of the platforms.
>
> Cheers!
>
> -----
> Gord Tanner
> Code Poet
> Research In Motion
>