Aaron sure, but it's not mutually exclusive. Require.js and approached I mentioned can be supplemented with a single js with a "build" of all the dependencies.
On Feb 23, 3:15 pm, Aaron Newton <[email protected]> wrote: > 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-b... > > ). > > > 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
