- From: Brian Kardell <bkardell@gmail.com>
- Date: Wed, 9 Jan 2013 16:55:40 -0500
- To: Clint Hill <clint.hill@gmail.com>
- Cc: Marcos Caceres <w3c@marcosc.com>, François REMY <francois.remy.dev@outlook.com>, "public-nextweb@w3.org" <public-nextweb@w3.org>
- Message-ID: <CADC=+jeQcndLBf6Lyfzf0vmcnpDp_KKf_RezO3s6xYQSi6x_dw@mail.gmail.com>
On Wed, Jan 9, 2013 at 4:53 PM, Clint Hill <clint.hill@gmail.com> wrote: > 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 > > > > > > > > > > Honestly - I think this is a red herring right now... Let's stick with what we have an iterate on it :) It will definitely not be hard to add or remove 7-10 lines of boilerplate in a couple dozen files later on. -- Brian Kardell :: @briankardell :: hitchjs.com
Received on Wednesday, 9 January 2013 21:56:08 UTC