Top 4 ways of organizing SPA code compared

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:



Every file in the source code of each application has been classified by three dimensions:

  1. Type of code (template, image, etc)
  2. Side (client, server or both)
  3. 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:

  1. app
  2. app component
  3. module
  4. library component
  5. company component
  6. environment

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.

Here is the comparison

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 🙂



Faulty arguments for having multiple application generators

Here are some arguments I have heard to support the competition between open-source application generator projects and my rebuttals.  Let me know if you see any holes in my logic.

Competition drives innovation

1) In capitalism, companies competing against each other drives innovation – TRUE
2) Open Source software is like capitalism – FALSE
3) Therefore: Open-source teams competing against each other is necessary to achieve innovation

In capitalism, people are motivated by money – a limited resource for which companies must compete. Innovation is a happy by-product of competition in this particular situation, but there’s more than one way to get innovation. Just look at all the innovation that comes from university research of teams that are either the only ones researching something or are cooperating with separate teams.

In open-source software development, people are motivated by a few things: reciprocity and social acknowledgment are up there. An opportunity to learn something new, a sense of community and just working on something cool without having a boss yelling at you about deadlines all factor into the motivation of a software donor.

But defeating the competition in order to capture market share and revenue are not in this list. This is what makes it so different from capitalism.

If you absolutely have to have a competitor, that’s not a problem. Here are some for starters… Microsoft, IBM, Oracle, Apple, SAP…..


The only way to achieve something great is for alternatives to fight it out

1) In the natural world, species evolve through the Darwinian process of competing for limited resources – TRUE
2) Open-source app generators are like the natural world – FALSE
3) Therefore: Competition is necessary for the evolution of app generators

In the natural world, species are unable to willfully design themselves however they want – with arms, legs, wings, gills and so on. So the only way for them to acquire functionality is through competition. This is different from software which can be designed however we want to an unlimited level of complexity and sophistication.


It is good to have multiple types of car, house, shoe, music, etc.

1) It is good to have multiple types of car because each one serves a different set of needs or tastes – TRUE
2) Open source application generators are like cars – FALSE
3) Therefore: It is good to have multiple generators to serve different sets of needs

Short answer: Regarding cars, most people want choices. Regarding application generators, most people do not want choices. They want excellence. See survey results ->

Screen Shot 2014-07-24 at 08.38.37 am

Long answer:

Cars are different from application generators. A car has limited and fixed functionality. A Ferrari cannot carry a family and a Sprinter can’t win the Grand Prix. They are stuck with their abilities and you can’t use one of them one way today and a different way tomorrow. But an app generator can generate both an SQL app and a NoSQL app. jhipster and CleverStack both do. Generators are general by definition and so one of them can be used to make applications of any sort.

But the analogy is still bad even if we limit it to just cars within the same class, let’s say 4-door sedans. Cars with the exact same functional value still have aesthetic value to differentiate them and justify their variety. For things that are purely aesthetic, like paintings, it is unquestionably good to have more than one because the aesthetic value of each is not subject to mathematical comparison and everyone appraises aesthetic value differently. But what if we remove aesthetic value from cars to improve the analogy to generators. Let’s say people are all blind and cannot tell the difference between how two cars look. Let’s say it’s a time when cars are all self driving, so blind people can have them. In this case, there is no good reason for having two options except to prevent monopolistic price gouging. Functional software like app generators has no aesthetic value and is free of charge. Its value can be completely measured by the number of hours of work spent by developers to achieve their goals and the performance of the generated apps.

So the value of a generator isn’t aesthetic but just mathematically measurable in terms of developer time and app performance. But what if some developers can deliver an app faster with one generator and others can do the same thing faster with a different generator? Isn’t this a case for having a generator to suit each style? To answer this question, we need to compare total time expenses – that under the status quo (with a variety) to that of a world with only one generator. It’s a tough calculation to do, but for starters, the latter sum would eliminate all the time spent by developers evaluating the options and switching around until they found the one whose style they liked best. The latter sum also eliminates all of the time spent by developers implementing things left out by their chose starter which is necessarily incomplete because the contributors are not on the same team and they are wasting time duplicating functionality. Moreover, in a world without standards, the vast majority of people come into a project whose style has already been determined by the founding CTO and, by simple probability, most likely not the style that best suits them assuming there is such. Everyone working on the team must use the same set of best practices. If each set suits different people, it’s unlikely that a given set of best practices is the best style for everyone (or anyone) on a team. So in a world with so much variety, this style- or preference-matched time savings is limited to one-man, new projects. Lastly, and possibly most importantly, in a world with standards instead of variety, all sorts of time saving tools and interchangeable components can be made that otherwise could not and documentation will be written that otherwise would not. So in which scenario is the total development time less: one with multiple generators to accommodate different styles or one with a single standard? I don’t think the comparison is even close.

Back to the cars. What about two cars that provide the same functionality but to different degrees – one is faster and the other can carry more and it’s not possible to make one car with the best speed and the best capacity. This is the case of mutually exclusive benefits. So the question becomes: Are there mutually exclusive benefits of an application generator? If so, then it is good to have more than one application generator. If not, then it is best to have just one that excels in every way. Some generators work with Node.JS and some with Java. It is in fact possible to have a single generator with options that let you use SQL or NoSQL databases. So I can imagine one with an option to use either Node.JS or Java, but haven’t seen one like that yet. The fact that Angular apps accommodate a variety of browsers makes me think it’s also possible for an app generator to accommodate a variety of application server platforms. But If it is technically impossible to do this, then this is a valid argument for having two generators and the list should be reduced from 20 to 2 instead of 20 to 1.

A better analogy is inches and meters. Is it good for us to have both inches and meters? No. There is no reason to have both. And since meters are in every way better than inches, there is no good reason why inches should exist. They do simply because of conditioning and historical roots which are not at all salient in a thing as new as an AngularJS application generator.


You should just use angular-seed because it is simple

1) angular-seed is simple – TRUE
2) Complex things are always harder to use and than simple ones – FALSE
3) Therefore: You should use angular-seed for simple projects. You can use another one for complex ones.

Something can be both powerful and good at simple tasks. My computer has only one operating system, but it is great for both simple things like running a notepad application and complex things like running computer aided design software. A car can move me around, entertain me, keep me cool, keep me warm, keep me dry, carry my things. Would it be better to have separate objects to serve each of these purposes? Would it be better to drive around in the winter without a heater and then pull over and go into a warming house whenever you got too cold?

With less to it, doesn’t that mean angular-seed is always easier to use? No. Standardization means that it is easy for anyone familiar with the standards to work on any project that follows the standard. Observance of standards determines difficulty much more than just how complex and capable something is. Switching to a project in a simple but unfamiliar system will take longer for someone than getting up to speed on another project in the same, sophisticated system.

In software, the ability to do simple things well and complex things well are not mutually exclusive. If you are just learning, it is much better to use a tutorial with step-by-step instructions and a functioning application than to use an empty application seed just because it can’t do very much. The Angular phonecat app is an awesome tutorial and would be even better if it had been generated by the best generator according to best practices and structure.

This argument is also short-sighted in how it looks at effort and time savings. Starting quickly does not mean that the entire development process is going to take less time. It will definitely take a lot longer. You have to count the effort of the whole process to determine which one saves the most work.

Comparison of single page application starters

Screen Shot 2015-01-22 at 7.28.59 pm

I decided to re-enter the world of app development after some time away from it. So I needed to decide which way to do that. Unfortunately there are lots of those and each one requires its own load of non-transferable learning investment. I always thought single-page apps were great and full page reloading was lame. So that narrowed things down. I watched a few AngularJS videos and decided it was as good a bet as any.

I didn’t want to do things like a beginner would. I wanted to do things like an expert would. I also wanted experts to do 90% of my work for me for free, because this is awesomely possible in software development. So I needed to pick a set of best practices for working with AngularJS. In app development, best practices take the shape of generators and examples. Unfortunately, there are lots of those too and I was faced with yet another decision. So I searched around and took structured notes and before long I had this giant comparison spreadsheet.


I’m sure I’m not the only one to confront this situation so if you are too, I hope it helps and saves you tons of time.  If you know any of these starters or in any way want to help improve the document, just let me know and I will add you as an editor. Enjoy, Dan


button (1)