client architecture #37
Description
I like that you're already thinking in terms of modules rather than architecture components when it comes to your javascript files, but I'd like you to extend that thinking to your templates, your styles, and even your assets (fonts and images)—they all belong to a particular (sub)view, so they should live in the same module folder
This would result in the disappearance of every folder except modules/ in your webApp/app/ (which you ought to consider renaming client/, right before you create a sibling server/ directory into which you put webApp/lib/, webApp/server.js, and webApp/package.json).
The guiding principle for organizing your code should be the GUI. Consider each component of the GUI a module, and group all relevant styles, templates, and logic together. There will be modules that are not part of the GUI, e.g. a data access layer, or model logic, but that's fine—modules don't have to have templates and styles.
You'll probably encounter the need for shared GUI components (your login form and your signup form might share form validation logic as well as interface elements). That's fine, too—pull them out into a ui-kit module, perhaps.
One thing you'll find that sucks about this organization is that the number of resources you need to include in index.html is now 2x the number of modules. You can use grunt, however, to setup a concatenation process that bundles your js/css into individual files and leaves your index.html with just a pair of includes, one each for js and css.
One thing that doesn't suck about this organization is that it lends itself very nicely to creating directives for every level of GUI abstraction, which can leave you with a very flexible front-end code base, and makes it easy to open-source parts of the client that you're particularly proud of.