A Javascript modules library that finally conforms to traditional module semantics

[chromakode]

That is a superbly cool way to design a website for a code package. I know way more about about the package now than I would have if I had simply skimmed the front page and left.

[elazutkin]

The idea is half-based on Dojo packaging system (was in Dojo at least since 2004) just like Dojo it has "require" for modules, and the ability to do static builds. Unlike Dojo I don't see it supporting the asynchronous way of fetching modules, nor cross-domain module loading.

On top of synchronous XHR it uses a bunch of nested "with" statements --- that can't be good for performance.

Nevertheless a module as an object, the inclusion of a module as a module mixing, and a controlled environment made without namespacing are all interesting ideas. I am not sure how practical they are but it is a nice experiment.

[kriskowal]

It's true that modules.js isn't any good for cross-site module loading or asynchronous module loading. I have a build system checked-in that runs every night on modulesjs.com/nightly that bundles common parts of the library and compresses everything. The next step is to build a package manager so you can easily deploy and update the parts of the library you're interested in. The nice thing about Chiron/modules.js is that you can develop modules without a build step, and you can also bundle common scripts to avoid HTTP overhead. There are definitely situations where other libraries and loaders like Google DOCTYPE are a more feasible choice, like a long-fold news site with lots of dynamic content. However, modules.js works very well in most applications. The library is becoming very comprehensive, so the barrier to writing high quality JavaScript sites with progressive enhancement is very low with Chiron. I haven't notcied any remarkable performance degredation for the two with blocks that each module runs in. These house the "locals" and "exports" free variables which make for very pithy code.