I'm working on an Angular app with a Java backend, so much of the directory structure is dictated by Maven. Also, for what it's worth, we don't have a "single

I'm working on an Angular app with a Java backend, so much of the directory structure is dictated by Maven. Also, for what it's worth, we don't have a "single page app" (with multiple controllers or whatever). We have a "small number of pages app". This allows for limiting the scope of what is done in each page a bit. Also, while we are not constantly reloading pages like the legacy app this replaces, we occasionally load a new page, which hopefully deals with any resource leaks our imperfect code may have had. That said, within the source directory for client side web files, we have the following: * html/ - app pages (a small number of files) are within this directory. -- html/help/ - sundry help pages put together by analysts are stored here. * css/ - probably overkill, but the main css file is here, and, so far, an alternate "skin" for a subsystem of the app. * js/ - empty in the source, but we do concatenate js files and place them in this spot in the final deployment package (.war file) -- js/lib/ - 3rd party library scripts (e.g. - jQuery, Angular, moment, Ramda ...) -- js/<<app name>>/ - in house scripts. There is a (short-ish) controller script for each page, and perhaps 6 to 10 shared utility scripts. The utility scripts tend to be somewhat long, rather than having hundreds of files, which really bothers me. E.g. - "tags.js" has the directives ("tag libraries", although there are a few custom attributes as well); rest.js is a wrapper around $http and some error / message handling code that does communication with the server. I can't stand the directory structure, which I attribute to JEE historically, that has hundreds (thousands?) of files, and grossly redundant "MaryHartman/MaryHartman" / "Smurf" / "Bat" naming style (directory bat contains BatMobile.src; BatPhone.src; BatBelt.src; BatShit.src and so on) Also, much of what is in the utility files are just single functions (within a namespace object), rather than classes. Currying goes a long way to inject dependencies into a chunk of code, rather than making a bunch of one-trick-pony (single action method) classes.