No problem, thanks for the feedback. If in the future you decide to adopt something like a top-level require() call or something closer to CommonJS design goals, please give the format as implemented in RequireJS consideration. Even if you do not want the actual implementation, if we can agree on API, that would be ideal.
Having the direct dependencies for a module in the module allows for easier decentralized loading of code across domains, and using a function wrapper around modules works best for performance/allows easy async loading, even cross-domain. It also allows some nice scoping features, and multiversion support. However I can appreciate that MooTools may not need all of those things, particularly if you have a system works for you today. Please feel free to contact me any time. Kudos to the MooTools community, I really like MooShell and Forge! James On Tue, Feb 23, 2010 at 9:07 AM, Aaron Newton <[email protected]> wrote: > Hi James, > You've done a lot of nice work with require.js. At the moment, we haven't > committed to adding any sort of markup to our scripts to support this kind > of loading. We don't want to add the dependency graph to the overhead of the > download. At least not yet. We have moved away from scripts.json, which had > numerous limitations, and have adopted yaml headers that have "requires" and > "provides" values, which should make it possible for you to create a script > that automates the wrapping of any mootools code with your own. To > elaborate, you would need to parse the header of the file, and then output a > version with your syntax around its contents. This may or may not cause > issues where certain global variables are defined though. > Regardless, I don't think we'll be implementing this in MooTools itself yet. > I've forwarded your post on to our developer mailing list for further > discussion. > Thanks for sharing this. We'll give it more thought and stay in touch. > Aaron
