Why do we need a framework at all?

Opportunities

  • Establishes a unified opinion on how to construct a web application.
  • Frameworks enforces their patterns and opinions through an inversion of control.
  • Broad developer community and support.
  • A framework need not encompass every aspect of app development.

Risks

  • Pace of advancement is bound to framework authors.
  • Code bloat.
  • Vendor lock.
  • Perfomance degredation.

Narrowly scoped tools mitigate risks.

  • Composing narrowly scoped tools to solve specific areas of app development allows us to evolve quickly with minimal disruption. 
  • Narrowly scoped tools tend to have fewer unused features.
  • Narrowly scoped tools allows us to adopt tools without structuring our organization around it.
  • Narrowly scoped tools allow for highly optimized implementations.

Why React?

Criteria

  • Community
  • Library size
  • Focus responsibility
  • Framework Complexity
  • Framework Flexibility
  • Change cost (to and from)

Why We Like This Solution

React has very large and growing community supported by Facebook:

Community

 

Facebook is heavily invested in React (Newsfeed, Instagram, Messenger, Ads Marketplace etc.) and has a number of dedicated engineering resources working on the project. This dog-fooding and investment is not present in any of the competing frameworks.

- https://blog.formidable.com/using-react-is-a-business-decision-not-a-technology-choice-63c4641c5f7#.usworp6gi

Why We Like This Solution

  • It is on the small end of the larger frameworks.
     
  • It can  be complete server-side rendered if desired, reducing the library payload size to zero.

Library Size

Why We Like This Solution

  • React is narrowly scoped.
     
  • It is only concerned with the view layer.
     
  • React encourages components that also have a focused responsibility.

Focused Responsibility

Why We Like This Solution

  • React has fewer concepts and smaller a learning curve.

Framework Complexity

We found that you can learn React to a high standard in just a week.

- Airpair

Why We Like This Solution

  • React's focused scope means it plays well with other 
  • Small learning curve means lower cost to change.

Framework Flexibility

Why We Like This Solution

  • There is a learning curve with any new technology. React has a comparatively low one, reducing initial productivity costs.
  • React focuses on making applications more predictable, accelerating development while reducing bugs.
  • React is inherently componentized, increasing reuse, reducing redundant work.
  • React reduces cost of future change by virtue of being more narrowly focused

Change Cost

Why We Like This Solution

React fits with our efforts to get away from monolithic application development to a modular/service/contract oriented one. It facilitates a more simplified composable way of constructing applications and gives us greater flexibility in how and when to evolve.

Domain Models

App Logic

Presentation

Angular

MWS

Client

Server

Handelbars

Node Express

Primer

Handelbars

Client

Server

React

fetch

React

Client

Server

fetch

Redux

Redux

JS Stack

Framework Scope Comparisons

React is da bomb.com. 

- bruce

React hastens the work. 

- mike gibby

I like it. 

- matt poulson

It's all sunshine and unicorns. 

- j. golden anderson

I heard this was going to be catered. 

- cory brown

We feel React and the architecture it encourages reduces overall app complexity, has a smaller learning curve and provides a good migration strategy. 

- the stack team.

The word on the street.

Support/tooling

  • Used by hundreds of organizations of all sizes including:
  • Facebook
  • Instagram
  • Reddit
  • Yahoo
  • Github
  • Kahn Academy
  • Netflix
  • Pivitol Tracker
  • The New York Times
  • Mozilla
  • Airbnb
  • Atlassian
  • BBC
  • Instructure
  • Intuit
  • Uber
  • WordPress.com
  • Wired

Support/tooling

Support/tooling

  • Excellent documentation
  • Plethora of video courses
  • Active and welcoming community
  • Supported by all modern workflow tools
  • Plugins for all major IDEs/Editors
  • Tools exist for automated refactors and upgrades.

Given that Angular 1 has a shelf-life, we would like to provide a more future friendly option.

Why can't we stay on Angular 1?

We can. The stack team will continue to support Angular 1 for the foreseeable future. However, as with all technologies, eventually Angular 1 will no longer be a viable option for teams.

What about Angular 2?

The stack team will provide expert help for teams who wish to use Angular 2. We will not provide tooling.

One
More

Thing

We'd like to brand what we do as the JavaScript Stack

Given we are recommending a modular approach to front-end architecture not dependent on a single technology, we intend to rebrand the Mobile Web Stack to the JavaScript Stack to be more inline with our actual role and with the other language stacks.