What have we learned?

Common Narative

Web Components

The Future?

• A proposed browser api specification as well as an architectural principal to follow
• Custom elements: an API for registering your own implementation for HTML elements
• Encapsulated; Shadow DOM and CSS scope
• Think <budget></budget>
• Draws together HTML, CSS and JavaScript (imports and templates)
• Events and event listeners for communication
• A standard browsers are purported to be following in the near future
• By following this architectural style we would benefit from front end features that are loosely coupled from the application itself (reusable in theory and more testable in isolation)

Component Hierarchy Tree

This is not an entirely new concept to us, we have "directives" in AngularJS.

They are however somewhat convoluted in their setup and not something that is enforced during development.

ECMAScript 6

(Harmony / ES6 / ES2015)

• ECMA is a standardisation body to guide the path of JavaScript (an implementation of ECMAScript)
• Current widespread browser support for ES5 spec 
• ES6 is the new specification and has been released this year
• Browser support is minimal therefore use requires tooling to convert back down to ES5
• Brings in a new module and dependency concept for organisation and loading of code
• ES7 spec already being worked on (decorators etc.) 
• By developing in the latest syntax now and trans-piling down for compatibility we should always be able to benefit from an improved cosing experience and keep up to date
• TypeScript is a superset of ES6 allowing strongly typed ES6 modules and has its own transpilers

Problem Statement: There are a number of frameworks and approaches that are in the ether which aim to aide development of modern front end applications, there is no silver bullet.

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.

As a loose criteria we looked for the minimum of a component based approach, the learning curve, adoption/activity/popularity, gut feeling after use and discussion on pros/cons.

List Overview

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

Angular2

Pros

• Much simplified compared to ng1
• Re-written for a reason to follow perceived future market trend 
• Believe a simpler learning curve, once initial concept is grasped
• Ability to write in ES6 or TypeScript giving a more familiar feel for C# developers
• Framework built in TypeScript which is a Microsoft initiative who have been working with the Angular team
• Uses dependency injection
• Adoption rate will be high? (AngularConnect an illustration)
• Built by Google

Cons

• Still in Alpha stage, release a moving target?
• Code could feel foreign to start with
• Documentation or tutorials currently lacking
• "Magic syntax" own conventions for bindings and events
• Was tricky to get setup (believe this down to documentation and getting used to ES6 new world)
• Need to stop thinking in ng1 world
• Stack trace still seems hard to fathom for framework errors

https://github.com/StepChangeCharity/angular2-playground

Aurelia

After doing the initial reading on this it became apparent of the similarity of this and Angular2 (core ng2 member Rob Eisenberg left to do Aurelia instead). For this reason a general consensus was reached to park for the following reasons:  

• Only real syntax and structural differences
• With this being the case it made more logical sense to keep Angular2 in the pot for the perceived community and adoption rate

Backbone.js

Pros

• Established framework, one of the earlier offerings (2010 bringing MV* to the masses), and therefore has a high number of plugins and extensions
• A flexible framework allowing room for own design decisions (sold as a library not a framework)
• Small in size on its own (however may be a mute point if you need to package with other libraries)

Cons

• Adoption rate has decreased significantly with the arrival of more "modern" frameworks 
• No inbuilt offering for web components, although nothing to stop using it with libraries such as Polymer
• A flexible framework but can often lead to the fact it is not enough on it's own (i.e. Marionette, Mustache)
• Potential hard dependency on DOM library for view manipulation (such as JQuery)
• Heavy on DOM manipulation
• Architecture unclear => 
• Feels verbose (as it's largely unopinionate it doesn't help you as much and doesn’t write as much of your code for you) and unwieldy in comparison to others

Breeze

After doing the initial reading on this it became apparent that Breeze is not a standalone tool for creating user interfaces but more a library for working with and managing rich data in JavaScript applications.  For the following reasons this has been discounted for the time being:

• Data management library
• May be able to integrate into whatever framework we choose when looking at data calls
• Would fit better in stage 2 or later down the line

Ember

Pros

• Has its own Ember CLI helping with builds and scaffolding, setup out of the box, up and running fairly quickly
• Ember 2 just been released focusing on components and W3C spec, React style data flow and working on routable components
• Strong architecture principles
• Supports ES6 and JS modules
• Includes an optional Ember data layer
• Performance improvements 

Cons

• Opinionated convention of config approach (based on Ruby/Rails approach) could feel foreign and learning curve steep
• Appears to be a lot of API revision and version change in the past

Flux & React

Pros

• Encourages component based architecture 
• The stack trace is more follow-able than others 
• Chrome extension provides a virtual DOM view of your application, easing debugging
• React can use ES6 syntax 
• Updates to the UI are unidirectional (no two way data-binding) 
• JSX can also be used when building native apps (note native, rather than hybrid) 
• Flux can handle dependencies between API calls
• It's released and being used
• Built by Facebook, and used for their website and apps

Cons

• It’s verbose
• Large applications could be difficult to navigate
• JSX is unique to React

https://github.com/StepChangeCharity/react-playground

Knockout

Pros

• Small in size (13kb)
• High browser compatibility (IE6+ for example)
• Well documented, been around a long time so plenty of examples / plugins as well
• Data binding and observerables
• Good separation between HTML and JS, not intrusive (data-bind)
• Has concept of components (not as strong as other offerings)
• Microsoft backed (creator from there), examples with .Net sites (not the model we will be following with SOA)

Cons

• No strong opinion for structuring of code (could get unwieldy), no out of the box modularisation
• Missing framework elements such as routing 
• Doesn't feel like one could write a large scale application with it
• Reported performance problems
• Adoption rate declining

Meteor

After doing the initial reading on this it became apparent that Meteor is more than just a framework for creating user interfaces. It looks to tackle the bigger issue of publish / subscribe data patterns and synchronisation and being and end to end mobile and web framework with pure javascript. For the following reasons this has been discounted for the time being:

• Offering out-of-scope at this stage
• It can integrate with existing applications written with technologies such as Angular or React so there is nothing to stop us looking at this later down the line
• It may be stepping on the current role of services

Polymer

Pros

• Follows web component API browser spec
• Polymer is sugar syntax on top of the API
• Pure encapsulation due to component spec approach
• Native events used to raise change, meaning standard JavaScript can hook into these
• Google created / adoption in house and a couple of external sites

Cons

• Uses polyfills to bridge browser gap, can be weighty and lead to performance issues
• Current documentation appears to be sparse
• Significant shift between versions 0.5  > 1.0, export/import tools needed, stable / future rework?
• UI / component library only, does not have the same offering as a comprehensive framework, would require own approach for routing etc.

Riot.js

Pros

• Simple, nice to work with 
• Small framework / API
• It’s simple to pick up (small API => less to learn)
• Noticeable productivity 
• Doesn’t try and “hide” javascript
• Readable stack trace
• Component based architectural approach
• ES6 support
• Unidirectional updates
• Event dispatching like flux

Cons

• Not supported by a “big name”
• Isn’t the most “used” framework (Stackoverflow tags for instance)
• Routing seems simplistic
• As it’s simple we may hit an issue where it can’t do what we want 
• Performance in large scale application is unproven
• Debugging can be tricky (could be down to limited experience with workflows / builds)

https://github.com/StepChangeCharity/riot-playground

Next Steps

Take Forward

• Angular2
• Aurelia
• Backbone.js
• Breeze (as part of a data layer?)
• Ember
• Flux & React
• Knockout 
• Meteor (later maybe, unrelated to this task)
• Polymer
• Riot.js
• "No framework"

• Share progress to date with both Development teams and capture buy-in on approach and/or objections => resolve
• Create a spec for a mini application that touches all facets we wish to cover (i.e. data calls to APIs, routing, testing)
• Implement spec in the selected frameworks utilising whatever resource we can
• Share code with both Development teams
• Compare, contrast, discuss .. choose?

Finally

Once a framework or direction is chosen this is not the end of the work that needs doing:

• Standards / architectural guide
• Developer workflow
• Templating / snippets
• Styling CSS
• Builds
• Testing (whilst developing + automation)
• Digital?

(not exhaustive)