If I was dealing with 40+ diverse services that I needed anywhere within various JavaScript apps, I'd probably write some kind of mediating service broker:<p><pre><code> var App = new YouNow();
var Bcast = App.Api('BroadcastService');
Bcast.Api.send(msg).then(cb);
</code></pre>
Your code doesn't have to care about where the services come from, it just has to comply with the services' APIs.<p>Thinking about your code structure as backend-provided services gives you the flexibility to do a Require.JS-style async dependency loading approach if needed. Imagine the following defined in api/services/BroadcastService/index.js:<p><pre><code> service.define('BroadcastService',
['MessagingService',
'VideoTranscodingService'],
function(MS, VTS) {
// do stuff with services,
// return a promise
}
);
</code></pre>
A style like this allows you to mix and match a bunch of different interesting architectural approaches, with relative ease, and the safety of decoupled software components.<p>As usual your sticking points with this kind of hierarchical component system will be caching and out-of-band (component-to-component) messaging and state changes. For instance: what happens to the notion of a global 'Session' object?
<i>edit:</i> removed snark.<p>You should not be worrying about object size. Write libraries in a way that makes sense for your problem, then use Closure compiler to strip the unused code from each application.
I've been exploring both Alt. 2 and Alt. 3. 2 with AngularJS and 3 with Backbone+Marionette. Evental communication within Models, which are entities, to views and controllers is easy and fun. A model is essentially a service anyway, so methods are more intuitive to name.