Angular has been the recommendation from the stack team for approximately 3 years.
At that time, Angular was at version 1.2
It is now at version 1.5
Most of the deployed Angular apps at ICS are using version 1.2 or 1.3
Around September 2014, the Angular team announced plans for Angular 2
It was to be a complete rewrite of the code base
It would also be backward incompatible.
And would have no migration path.
The Angular received a lot of pushback about the lack of a migration path from 1 to 2
They decided they would spend the next 2 releases (v1.4 and v1.5) to create a migration path to 2
Many important things required for a migration path to v2 missed the 1.4 release
They were later release in 1.5
Additionally, the paradigm with which application were to be approached with Angular changed dramatically from 1.3 through 1.5.
The paradigm change was necessary in order to create a meaningful migration from 1 to 2.
Most of the deployed Angular apps at ICS are using version 1.2 or 1.3
It is clear that for ICS to move to Angular 2 would be nothing less than a complete rewrite and paradigm shift.
Given this necessity, it was important to see what options fit our organizational goals
We identified several candidates.
A major goal in choosing a new framework is to reduce complexity
Another is to reduce maintenance costs
These goals are closely linked.
These goals are primarily not a problem of technology, but of priorities.
A given technology can have some effect by either exacerbating, or smoothing a problem.
Yet another goal was to facilitate reuse.
Reuse of code, but also of knowledge.
Knowledge at a language or platform level is vastly more reusable than proprietary framework knowledge.
Other goals included community support, learning curve, scalability, library size and server size renderability.
The latter two were of particular concern for public facing or global sites.
After weighing all the pros and cons of each option. It was pretty clear Flux met our goals the best
Facebook developed the architecture to go with React.
Flux's main feature is unidirectional data flow.
It also borrows heavily from function paradigms.
It is flux's functional paradigms that scores most highly on the maintainability and complexity goals.
Functional programing can obsolete an entire category of errors caused by side-effects.
The unidirectional data flow sores in the complexity category too. This kind of architecture sees a flat growth of complexity as code base size and feature sets increase.
There are many libraries that embrace flux. Most of them are significantly lighter than those that embrace other paradigms.
The most common library used with Flux, React, is on the small end of the more common JavaScript frameworks.
The majority of flux embracing libraries are server side renderable.
This can offset payload size concerns in cases where applications are payload sensitive. Projects can elect to render on whatever side of the network boundary their needs require.
Even with Fluxy libraries uncommonly small size, we can confidently deliver a fully feature front-end application environment for ~65K in total library size.
To put that in perspective, Angular 2 weighs in at 121K under the same conditions.