[caseydurfee]

This is a neat idea, however, I ended up avoiding this approach myself on the last big project I did because my personal bugaboo is mixing metadata (requirements) with data (code). Hardcoded dependencies between JS modules leads to front-end spaghetti -- to me it's only a marginal improvement over inline script/style tags. It forces frontend devs to know too much trivia about how the backend/devops code actually makes the sausage.

A JS module or HTML widget should be able to declare what it needs without hardcoding how that dependency gets fulfilled. (eg. if it's loading on a local dev box, do this, in production, do that, running server-side in a Node.JS setting or in a test suite, do this other thing.)

So the system I built allows devs to declare the resources needed by a feature, then the asset management system converts those requirements into LABjs script loader code that gets output -- more of a makefile sort of approach. That means devs can write more general, reusable, testable JS modules (and corresponding HTML templates) that can load through a script loader for better performance, but aren't tied to a particular deployment environment or how the script loader works under the hood.

I wish there was a more natural way for logical components on the page to declare the resources they need without mixing code and metadata. HTML Web Components, for example the [Polymer project](http://www.polymer-project.org/), are possibly a step in the right direction, but I don't think they address intelligently lazy-loading requirements.