Are there any problems with nesting app-specific B

Question

I am working on structuring a large application that has several, discrete client-side applications. I am using Backbone.js for structure and Require.js to manage dependencies.

Here is how I would like to model things so that I can have common functionality available to any of these applications:

-- libs
-- models
-- collections
-- templates
-- views
-- apps
  -- app_one
    -- libs
    -- models
    -- collections
    -- templates
    -- views    
  -- app_two
    -- libs
    -- models
    -- collections
    -- templates
    -- views
main.js

I am curious to know if anyone has done anything similar to this and are there any obvious pitfalls to this design that I am not considering.

The main benefit that I see is that I can group common libraries, models, collections, templates, and views in the root of the structure and any of the sub-apps can import them as needed or defined app-specific assets in their own nested structures.

Answer 1

This makes sense and is how most people do it I would think.

I typically differ from that in that I don't separate models/collections & views. Instead I have a directory for "modules". A module would typically consist of a single file with one or more models, the relevant collections and views.

Also be aware that you will likely end up with having multiple versions say of jQuery in your lib folder, because you might have the time to update one app but not another.

While it is true that require.js makes your structure irrelevant, it is still a good idea to keep your code organized.

Answer 2

You dont even need to nest anything with requirejs . Your main lib can live in its own folder and differents apps can have their own folder too anywhere on the harddrive. The only issue lies in the way you would call all your dependencies with requirejs and wether or not you would use r.js to bundle different apps in a single file.