Obviously, I don’t want to concat my js with what google is serving.

So is module loading better if what I’m bringing in is coming from google’s servers?

@Kris, I’ve forgot, you can “include” as well files in archetype using a Archetype.require with some params for it to be synchronous (it’s asynchronous by default with a callback, because synchronous will freeze your browser during the load else).

For the logger system, you should look at nitobibug which is quite amazing, we plan to introduce it in one of our default logging system for the next release.

@JustinMeyer : get at least a 1.1 firebug version and you’ll have it. However, for cross site js loading, using xhr is not a good and it can be desirable in order to load your js application faster when you’ll want to put it in production (using static1.js.mydomain.com, static2.js.mydomain.com, etc. in order to “override” the 2 request per server limit of http protocol …).

As you said, javascript compression is easy… but is very unhelpful for debugging, that’s why providing an api like Archetype provides a good to handle both development and production, using or not compression a cross site loading!

And this system doesn’t stop to js loading, but handles also templates and css loading associated to the component ;)

@Bredy my apologies for the cursory examination of YUI loader.

@slightlyoff I read Dojo’s loader a year ago and found a lot of inspiration there. It has had a major release since then, so some things have changed and I never fully grasped the complexity of the system. My comments about the addLoadListener were rather attributed to the Goog library, which was also inspired by Dojo.

@temsa Archetype is interesting. However, it still doesn’t get you the simplicity of include(”module.js”) or require(”module.js”) (which imply dependency, are loosely coupled from each other, and mnemonically map to analogs in other languages readily). I will be giving it a more thorough examination and will probably contact you or blog about it.

@JustinMeyer You raise a valid point. I get much less useful debugging information out of Firebug with modules.js. However, the module loader includes a debugger module like Firebug-Lite that can be opened in any browser on any web page running modules.js. The debugger console also runs in a module, so you can do “include”, “require”, and logging calls from the command line. The module loader also marks up functions with module origin information and adds logging functions to the module scope so It’s easy to add trace messages to your code, like log(”Found: ” + repr(object)). I also make an attempt at rethrowing exceptions with adjusted file names and line numbers, but I’ve had mixed results and could definitely improve on these points.

@Nosredna In a production system, you really shouldn’t have a clump of script tags anyway. Your application should be packaged, and maybe event compressed, in one file. However, the Module loader would be useful in cases where you have a VERY large JavaScript application, where much of the application’s code isn’t used immediately.

As this post seems to be filled with people promoting their own technology, I might as well throw JavaScriptMVC’s hat into the ring.

With JavaScriptMVC, you can’t do loading like this, but it’s not important because the compression is so easy. Even easier than … DOJO. You don’t have to make code changes, but you have to write extra code. Take that Alex. Bwhahaha.

Btw, I hope you can tell I’m joking. Dojo’s got it all. I couldn’t have done the new compression system without ShrinkSafe.

Full loading process, including a final code starter, recursive configuration, etc. But in Archetype, it’s just 10% of the framework and it’s way more practical to use dependency management in components thant just registering dependencies in a files between libraries!

If you’re not convinced, check out the 0.8.0-beta we’ve released some hours ago : http://sourceforge.net/project/showfiles.php?group_id=194362

http://archetypejs.org

@ Kris : it would have been great to get you in our team ;)

It seems the author of this system (which looks like good work) didn’t really take any care to investigate Dojo seriously before inaccurately characterizing it. Dojo’s package system DOES handle recursive dependencies but ALSO provides async module loading after pre-processing, but that mode still handles recursive dependencies. That allows the Dojo package loader to work in CDN environments without serious changes to existing code other than the addition of provide()/require() statements.

Furthermore, in addition to his inaccurate statements about the basic function of Dojo’s package loader, he’s also wrong about the way that Dojo manages onLoad handling. The Dojo system doesn’t fire handlers registered with dojo.addOnLoad() until all dependencies have been satisfied, both in the local (XHR) and x-domain cases. Dojo’s package system ALSO integrates with Dojo’s build system allowing you not only to be able to easily load modules but also to coalesce/optimize them for deployment without code changes.

It’s great to see other toolkits picking up features which have been in Dojo for years now….hopefully Kris will take another look at Dojo and talk more accurately about it in the future.

Regards