Re: Call for vote on structure - Re: Please assign yourself on GH

I'm familiar with r.js and how it concats modules. I think my point is
more about the functionality it induces.

We ought to have a compiled output that does not have any dependency on a
loader. Wrapping all the code in "define" statements is cruft for AMD and
not necessary to our adopters. More over it creates an async nature to
WebIDL that I think is functionally detrimental. The purpose of WebIDL is
to be "native"-like and when you make it async you step in the opposite
direction.

I'm also wanting a nicely organized structure to our code and dev cycle -
I believe we can do it without AMD.

Does this make sense?



On 1/9/13 2:34 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:

>
>
>
>On Wednesday, January 9, 2013 at 9:11 PM, Clint Hill wrote:
>
>> Marcos - Happy to vote - but want to make an observation/point before we
>> do:
>> 
>> RequireJS forces an async nature to the entire lib. This causes a blip
>>in
>> it's usability by prollyfills using it in a compiled state and even by
>>us
>> when we work with it in a decomposed state.
>
>Remember that the final code will just be a single file. The only
>advantage in using AMD right now is that it makes development a bit
>easier (IMO). 
>
>> I think there is a 1.5 choice:
>> 
>> I want to create a build system that composes the web-idl.js as a whole
>> for testing/running while allowing me to code in separated source files.
>
>That fine, we just run it through r.js. I'm doing that for the Web MIDI
>Prollyfill already and it works a treat:
>
>See:
>https://github.com/marcoscaceres/adlib.js
>
>> (I would point to the work that the Ember.js team have been doing in
>>this
>> aspect as guidance.They've done really smart things with mini-spade,
>> sourceMap etc.)
>
>Sounds interesting, if you have a pointer that would be great.
>
>-- 
>Marcos Caceres
>
>
>

Received on Wednesday, 9 January 2013 21:53:00 UTC