My only issue with this approach is that it's a client-side approach. I first built Depender to be a client-side only approach, then built a server side approach. The differences in performance are huge; like 50x. If MooTools fetched each component it needed on demand it would be very slow. That's why Depender is a server side app with a client-side client.
On Tue, Feb 23, 2010 at 12:49 PM, ibolmo <[email protected]> wrote: > Hey James. Thanks for contacting us. > > I'm taking a look at RequireJS. I've worked with Google Closure and it > appears that there's very similar language with RequireJS. > > While I continue to sift through the differences, could you outline > the differences in approach? > > Here's my summary of goog.require: > > Create file.js. > > Use goog.require for dependency with the namespace.class.name as the > argument: e.g. goog.require('goog.Uri'); > Use goog.provide for definition of a module: e.g. > goog.provide('goog.Uri'); > > To use this "uncompiled" you'd need to load base.js from goog (which > is effectively require.js) and do a goog.require('goog.Uri'); > Internally it'll try to load goog.Uri if you had also included the > file.js with the goog.provide. > > If you had not included the uri.js file then an error would be thrown > since there's no mapping. > > I think similar to requirejs is that you can "calcdeps.py" for > creating a file with all the dependencies for a file. You'd then > include the base.js, deps.js, and inside your other script or the page > itself do all the goog.require('goog.Uri') you'd need. > > --- > > Bottom line this is great. It's proven and it's able to move forward. > > The irksome is that document.write is slow (see various Steve Souder > posts in regards to that. In particular: > > http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/ > ). > > We had previously talked about a sort of require system for MooTools > but we had already started using the YAML module header. And since the > Forge (PluginsKit) is using it extensively it's unlikely that we would > eliminate the header and instead use require calls. Although there's > huge advantageous to using procedural calls (in particular doing some > kind of Class Mutator for Requires... @credit davidwalsh). > > Davidwalsh brought the idea to use a Requires mutator for Class but > because of the redundancy with the YAML header we started picking at > the idea. > > My (untested) solution is to XHR for the (local, or by proxy, or by > any x-domain solution) file and parse its headers. Then recursively > grab other files and its headers and so on. Once you're done > collecting the dependency branch for that file you'd eval and pop each > xhr'ed file content. > > I'm not familiar with the requirejs specifications on synchronous or > asynch loading of scripts -- I think I saw a john resig commit in > regards to blocking or waiting for a script to finish downloading. I > think that XHR and buffering the file content until has the advantage > that you can eval when ever you want. And as shown by Steve Souder, > it's faster than document.write and you don't have the rendering > problems in most browsers. > > > Anyway, I jumped the gun and already started to propose a solution. My > intentions was to greet you and thank you for your interest. I'd love > to hear from you about the above idea. I'm pretty sure that I wrote > this too fast and that most of the content is incomprehensible or I > forgot some details. You have my assurance that I'll be following, and > if I can, contribute to the discussion. > > Olmo > > > On Feb 23, 1:55 pm, James Burke <[email protected]> wrote: > > 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 >
