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
