incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: Unified phonegap javascript layer incorperating modules / plugins
Date Fri, 18 Nov 2011 19:47:05 GMT
+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 <alunny@gmail.com> wrote:

> On 18 November 2011 08:47, Gord Tanner <gord@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 <pmuellr@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
>>

Mime
View raw message