Question

I’m looking to implement backbone into a large web project with multiple “apps” that will be using it and I’m trying to figure out a good way to organize my files. The two I’ve come up with so far are:

js
+- models
|  +- search
|  |  +- result.js
|  |  +- ...
|  +- cart
|  |  +- item.js
|  |  +- ...
|  ...
+- collections
|  +- search
|  |  +- results.js
|  |  +- ...
|  +- cart
|  |  +- items.js
|  |  +- ...
|  ...
+- views
|  +- search
|  |  +- resultRow.js
|  |  +- ...
|  +- cart
|  |  +- itemRow.js
|  |  +- ...
|  ...
+- routers
|  +- search
|  +- cart
|  ... 

And

js
+- search
|  +- models
|  |  +- result.js
|  |  +- ...
|  ...
|  +- collections
|  |  +- results.js
|  |  +- ...
|  ...
|  +- views
|  |  +- resultRow.js
|  |  +- ...
+- cart
|  +- models
|  |  +- item.js
|  |  +- ...
|  ...
|  +- collections
|  |  +- items.js
|  |  +- ...
|  ...
|  +- views
|  |  +- itemRow.js
|  |  +- ...
+- routers
|  +- search
|  +- cart
|  ... 

I’m leaning towards the latter as it has clearer lines between sections of the website and keeps the apps together but our current structure of the back-end framework is much more like the former.

Answer 1

i would go with a modified version of the second… basically, drop the folders for m, v and c in each of your site sections. there’s really no need to separate these into subfolders when the file names and class names will already reflect what they are.

js
+- search
|  +- result.js
|  +- results.js
|  +- resultRow.js
|  +- ...
+- cart
|  +- item.js
|  +- items.js
|  +- itemRow.js
|  +- ...
+- routers
|  +- search
|  +- cart
|  ... 

looking at this layout, i still know that “item” is a model, “items” is a collection and “itemRow” is a view, because that’s the convention that you have set up. adding the extra layer of folder names just adds complexity and adds no value, in my opinion.

also – (you probably know this, but in case others reading this post don’t…) be sure to use something like require.js to consolidate / minify all of your js into a single file before deploying to your production environments. keeping code organized like this is great for development and debugging purposes. but when it comes time for a production system to use the code, having it split out into multiple files causes significant delays for the end-user. require.js solves this problem by providing an easy way to have both – organized files during dev work, and a single minified file for production.