The advantage is that this model has the potential to be ubiquitous unlike a server based model. It also allows users to simply drop in scripts from external sources. You can run it client-only with retained debugging and tool support. The export model can eliminate namespacing and provides several other advantages for scoping.
It requires a little more parsing on the server, but if a common syntax is decided upon, it can be used for server side tools as well. In my model I have three aliases: "use", "include", "compile". On the client they all function as "require". But "include" is a hint for a server tool to compile the referenced file into this one. "compile" does the same but also includes all it's dependencies. On Wed, Feb 24, 2010 at 1:47 AM, Aaron Newton <[email protected]> wrote: >> As Olmo mentioned, this can be optimized via a build step, once you >> are done developing, via a tool that is available as part of >> RequireJS: >> http://requirejs.org/docs/optimization.html >> >> And I am more than happy to add an adapter to RequireJS that forwards >> the array of dependencies to a server process if that helps the >> scenarios when a server is available. If you can give me pointers to >> the format you need on the server, I can work something out. > > For the moment, I'm still going to use Depender as it complies with our > current system. I don't categorically oppose something like this as an > implementation, but in general, I'm not in favor of it. I'll never use a > client-side solution for this problem; it's just too damn slow. And if > that's the case, then putting the dependency data inline in the file doesn't > make sense if (for my work) a server is always going to be doing the > building. > But never say never. If there's a portable implementation that comes out > from our or CommonJS or whatever that allows me to build my requirements in > one request and the rest of the MooTools developer community is onboard, I > certainly won't get in the way of it.
