TL;DR;
Why Flux?
- Change is happening to us
Angular2 amounts to a completely new framework - Rapid on-boarding and transition
Flux has a small learning curve -
Maintainable
The Flux paradigm can eliminate whole categories of errors - Scaleable
Flux apps do not grow in complexity as applications grow in size - Universal
Most implementations of Flux, including React can easily render on client, server and even be used for native apps - Size
React, a common Flux library, is moderate in size relative to other tools. -
Future Friendly (aka Change friendly)
Flux is not dependent on an library or framework. It does encourage narrowly scoped tool which cause less disruption when changed.
Why
Flux?
Where
We
Are
Angular
Angular has been the recommendation from the stack team for approximately 3 years.
Angular
At that time, Angular was at version 1.2
It is now at version 1.5
Angular
Most of the deployed Angular apps at ICS are using version 1.2 or 1.3
Angular 2
Angular 2
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.
Angular 2
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
Angular 2
Many important things required for a migration path to v2 missed the 1.4 release
They were later release in 1.5
Angular 2
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.
Angular 2
Most of the deployed Angular apps at ICS are using version 1.2 or 1.3
Choices
Choices
It is clear that for ICS to move to Angular 2 would be nothing less than a complete rewrite and paradigm shift.
Choices
Given this necessity, it was important to see what options fit our organizational goals
Choices
We identified several candidates.
- Angular 2
- Polymer
- Flux
- React
- Riot
- Winston Churchill (Web Components)
- No framework
Goals
Goals
A major goal in choosing a new framework is to reduce complexity
Another is to reduce maintenance costs
These goals are closely linked.
Goals
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.
Goals
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.
Goals
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.
Goals
After weighing all the pros and cons of each option. It was pretty clear Flux met our goals the best
How Flux Measures Up
Flux
Flux
Facebook developed the architecture to go with React.
Flux's main feature is unidirectional data flow.
It also borrows heavily from function paradigms.
Flux
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.
Flux
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.
Flux
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.
Flux
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.
Flux
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.
Why React
By Cory Brown
Why React
- 985
