I made a side-by-side comparison of how code is organized in some of the most respected approaches to single page app development.
Currently the comparison includes applications representing 4 different approaches, but I might add more. They are:
- a generator-angular-fullstack generated app
- John Papa’s gulp-patterns repository
- an ember-cli generated app
- a MEAN.IO generated app
Every file in the source code of each application has been classified by three dimensions:
- Type of code (template, image, etc)
- Side (client, server or both)
- Specificity (app-specific, etc)
The classification of code is entirely technology neutral. So, for example, there are no Angular-specific or Ember-specific classifications.
There are about 45 different types of code. Each type has between about one and ten combinations of side-specificity for a total of about 120 classifications. Not all side-specificity combinations make sense for all types of code . For example, “Tests (end to end)” has the side-specificity of “both sides, app-specific”, but not “client-side, app-specific”, because an end to end test involves both the front and back sides of an application.
There are 6 different specificities:
- app component
- library component
- company component
Some definitions for clarity:
module – a logical division of the features of an app
app component – a unit of code located in a single directory that may or may not have been originally gotten from a library but can be customized for the particular app. An app-specific component is different from a module. It is not a logical division of the features of an app, but it is used by one or more of them. Also, some code is app-specific, but located at the top level and not within a designated directory among other component directories. So I refer to such code as just “app-specific” and not “app-component-specific”.
library component – just like an app-specific component but it should not be customized for the app.
environment – development, production or test
I don’t know where company-specific files should go and did not see any examples of them in the subjects of this study, but we should think about these and I put them in the comparison under the types where I thought they would apply.
I also could not see examples of “components” that were only visible to a single module. All components within an app were available to all modules. So I did not create a “module component” specificity, but that might be another possibility.
If you would like other approaches added to the comparison, let me know. If you would really like other approaches added to the comparison let me know that you would be willing to add them yourself and I’ll make you an editor 🙂