I think the benefits of this approach are outweighed by the number of HTTP requests you have to send for individual JS files. In the majority of cases you'll find that all of your JS, bundled up and minified, loads faster than getting each file as it is required.

Yeah, there is a bit of an overhead with that. Module server - https://github.com/google/module-server seems like quite a good solution. Though I'd agree, for a large number of sites it's far better to bundle them up.

For a large scale website, where not every page would have a video player, gallery, or calendar, why load that JS and CSS, which can be very heavy. The benefits are definitely there without having to declare explicitly that a particular page needs a certain dependency.

We do a similar thing at Last.fm. We bundle our most commonly used modules in a single file. The rest all pulled in at runtime.

Paul wrote about it here: http://www.paulrhayes.com/2013-09/a-light-progressive-framew...

I wrote this post - feels like quite a simple approach. Would love to hear if anyone has done anything similar.

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.

We're doing something similar with YepNope that is included in Modernizr but it's not as simple as yours. We ran into problems where if there were multiple elements on the page with that dependency (usually a jquery plugin), only one would end up getting initialized. We ended up coming up with a complicated queuing system that queues up all of the initialization requests when it detects that it is in the process of being loaded, and fires for each in the queue after the dependency is loaded. I'm definitely curious to look into your method in terms of multiple items that need to each be initialized and how this is handled with your context require method or require in general.

Ah, I've not had to deal with sharing between multiple elements yet - I'm kind of hoping that when I do require.js would give quite a solid base for it. YepNope seems like a good choice for this kind of thing, especially that it can bring in css assets too. Would be awesome to bring in all related assets for a element