Where did we get to?

Initial Approach

We picked a handful of what we believe to be the more prominent frameworks and libraries around to get an initial feel for what they were about and whether they are worth investigating in more detail.

We applied a loose criteria for selection ranging from market steer to professional opinion after high-level use.

Started with ...

• Angular2
• Aurelia
• Backbone.js
• Breeze
• Ember.js
• React & Flux
• Knockout
• Meteor
• Polymer
• Riot.js
• "No framework"

Investigate further ...

• Angular2
• Aurelia
• Backbone.js
• Breeze 
• Ember.js
• React & Flux
• Knockout 
• Meteor 
• Polymer
• Riot.js
• "No framework"

Recaps ...

Angular 2.0

• Created by Google
• V 2.0 being adopted in-house at Google for internal applications (AdWords etc.)
• Core project team with community involvement
• Complete re-write compared to Angular 1.x
• Written in TypeScript (ES6 superset)
• Speed & performance a focus
• Web component standards support, routing, dependency injection, animations, mobile, accessibility, internationalisation
• Modular library design for loose coupling 
• Infancy, beta stage around corner (check)

• Created by the community
• Core contributors with community involvement
• Used by KickStarter, Discourse, Apple Music
• Recently moved major versions to 2.x, built upon 1.x
• Upgrade focus; rendering, routing, data flow, life-cycle hooks 
• Written in ES6
• Custom components, templating, routing, data library, CLI tooling
• Modular library design for loose coupling 
• Version 2.x relatively new (Aug 2015) but actively worked on 2.1.x currently

Ember.js

• Created by Facebook/Instagram
• Core project team with community involvement
• Used internally for Facebook components, WhatsApp, Instagram, New York Times
• Not yet at version 1.0 but "production ready" at
  V 0.14.2
• Written in ES5
• UI focused, component based approach, Virtual DOM, one-way reactive data flow, server and native rendering potential
• Stable has been around in its current form for around 2.5 years

React

• Created by Muut
• Small core with community involvement
• Can't find any examples!
• Recent non backwards compatable upgrade to 2.x
• Written in ES5
• Tiny download, simple syntax, minimal
• UI focused, component/tag based approach, Virtual DOM, one-way reactive data flow, server and native rendering potential
• Stable has been 2.x since the beginning of 2015

Riot.js

For the eagle eyed

Some may have noticed that Flux has been omitted from the React investigation.

The reason for this is that on further investigation Flux is more of an architectural concept rather than part of a framework or something to use with React.

Valuable Lessons

Unidirection data flow

Dumb / smart components

Application reasoning

Library !== Framework

So far throughout this entire process we have interchangeably used the phrases "library" and "framework".

At the beginning of this second phase of investigation there was a stark realisation that we couldn't keep doing this as there is an obvious distinction between the two which raised a fundamental question ...

• Enough direction to get an application going 
• Opinionated infrastructure, but not restrictive
• Consideration for different consumers
• Forward thinking, but respecting the present

What exactly do we want?

Sounds like a framework?

Market Positioning

Lets have a look at how the products we have been looking at "sell" themselves.

A development platform for building mobile and desktop applications

Angular 2.0

A framework for creating ambitious web applications

Ember.js

A JavaScript library for building user interfaces

React

A React-like user interface micro-library

Riot.js

Going back to what we want, the top two points are key:

• Enough direction to get an application going 
• Opinionated infrastructure, but not restrictive
   

Our belief is that we are only going to get these from a framework.
 

Looking back at the first phase investigation, we ruled out the "no framework" option as we didn't want to spend our time with exhaustive infrastructure decisions among other concerns.
 

By using a library that doesn't encompass the bigger picture we felt like this would be akin to the "no framework" option and therefore felt like these were no longer a main option.

What are we left with ...

After much investigation, deliberation and discussion we believe Angular 2.0 is the correct route to follow.

Hopefully from the material you have seen so far you will be somewhat in agreement.

This is open for discussion so don't be shy.

Angular 2.0

Fallacy of a Perfect Framework

For me one of the real game changers that re-enforced the debate over library v framework, was at the Angular Connect conference.

It alluded to the fact that Angular started off conception as a framework, but with the progression over the years, lessons learned built upon and the near arrival of version 2 they believe the offering is now a "platform".

The amount of thought, effort, community involvement and cross industry collaboration is impressive and hopefully bodes well for the future.

Angular Connect Keynote