1. Interested people
1.1. James M
1.2. Frans
1.3. Thomas Sileghem
1.4. Aaron
1.5. Mo
1.6. Phil
1.7. Henry
1.8. Ayyaaz
1.9. Andi
1.10. Damo
1.11. Tom H
2. Decision criteria
2.1. Enables clear division of labour between dev and UI devs -JM
2.1.1. Perhaps allows for easy division of work between devs and UI devs
2.2. Low barrier to entry -JM
2.2.1. Smooth learning curve if possible and some idea of how to up skill new people and UI devs quickly
2.3. Make it fast to develop the "crud" that makes up 80% of most applications
2.4. Enable us to have consistent approaches across projects, to facilitate moving team members with minimal pain
2.5. Enable us to automate "the boring bits"
2.6. Good community support
2.7. Viable long-term future
2.8. Explicitly not a decision criteria
2.8.1. It doesn't have to be the fastest or most memory efficient - it just have to be Good Enough
2.9. Attractive to potential recruits
3. Contenders
3.1. Aurelia
3.1.1. Notes
3.1.1.1. It has a paid support plan which may be good or bad
3.1.1.2. In terms of framework/non-framework, I'd put Aurelia somewhere between React and Angular
3.1.1.2.1. It feels more light-weight
3.1.1.2.2. It has more obvious extension points
3.1.1.2.3. It is explicitly designed to bring in stuff from other frameworks when you want
3.1.1.3. Watch the 30 minute video on http://aurelia.io to get a good overview
3.1.2. Pros
3.1.2.1. Favours convention over configuration
3.1.2.1.1. It's philosophy of "making the defaults easy but make it easy to then expand" seems to fit very nicely with our vision for Apogee and NewOrbit development in general
3.1.2.2. Fun
3.1.2.2.1. Not if you hate MV* frameworks AN
3.1.2.3. Commercial add-on packs to be available under support
3.1.2.3.1. Controls
3.1.2.3.2. Mobile controls
3.1.2.4. Very extensible
3.1.2.4.1. AN More so than other frameworks?
3.1.2.5. It's a framework
3.1.2.5.1. AN More so than other frameworks?
3.1.3. Cons
3.1.3.1. Less mainstream
3.1.3.1.1. Less support from other libraries/frameworks
3.1.3.1.2. AN Much smaller talent pool will want to work with this
3.1.3.2. No support for Foundation Zurb for apps, for example
3.1.3.3. Mobile development less streamlined at this point
3.1.3.3.1. No support from Ionic - though that may change
3.1.3.3.2. Can publish with Cordova
3.1.3.3.3. Commercial add-on pack with mobile controls
3.1.3.3.4. AN Developing paid option called Aurelia Interface
3.1.3.4. It's a framework
3.1.3.5. AN Commercial
3.1.3.5.1. They are a for profit company. I believe this will end like ExtJs. Without the support of the community, which it will not get as a paid product, it will never be able to compete with the development efforts of Google or Facebook.
3.2. Angular 2.0
3.2.1. Notes
3.2.1.1. The fact that we currently use Angular 1.0 is irrelevant
3.2.1.1.1. Upgrading is not obvious
3.2.1.1.2. It is different enough that we'd have to re-train anyway
3.2.1.2. John Papa's 2.5 hour Pluralsight Angular 2.0 overview course is a very good and very dense introduction that covers pretty much everything
3.2.2. Pros
3.2.2.1. It's a framework
3.2.2.2. Very wide community support
3.2.2.3. Everything works with Angular
3.2.2.3.1. Ionic
3.2.2.3.2. Foundation Zurb
3.2.2.3.3. Etc
3.2.2.4. Easy to hire for
3.2.2.4.1. Though not convinced that really matters - it's more of a recruiter argument :)
3.2.2.4.2. AN No it matters
3.2.2.5. Good story for mobile development with things like Ionic that just make it easy
3.2.2.6. Very comprehensive framework
3.2.2.7. AN Has abandoned MV* and moved to a component-based model like React.
3.2.3. Cons
3.2.3.1. It's a framework
3.2.3.2. Favours configuration over convention
3.2.3.2.1. Very configuration heavy
3.2.3.2.2. Irritating need to specify dependencies in what feels like unnatural places
3.2.3.3. Maybe extensible but I suspect it's not as easy - please correct me?
3.2.3.3.1. AN Why would it not be?
3.2.3.4. Not fun (at least to me)
3.2.3.4.1. AN Perhaps, but what is not fun is cleaning up or working with the mess of most apps built on MV* frameworks
3.2.3.5. Maybe personal taste but templating pattern is horrible
3.2.3.5.1. confusing
3.2.3.5.2. goes against html conventions
3.2.3.5.3. too different to angular 1.0
3.2.3.5.4. AN Strings vs JSX is a loss, probably because it was too big for the team to bite off. But if your comparing from the viewpoint of an Angular 1.0 template of course it's going to look like crap, because in Angular 2 templates mean something else.
3.3. React
3.3.1. Notes
3.3.2. Pros
3.3.2.1. It's not a framework
3.3.2.1.1. AN Agreed
3.3.2.2. Does ReactNative mean mobile is easier? Is it even relevant or is it something quite different?
3.3.2.2.1. AN Easier? That is a very overloaded word. Less costly. More maintainable, more customizable, more performant, Yes.
3.3.2.3. (can be) very fast
3.3.2.4. Extremely flexible
3.3.2.5. Fun
3.3.2.6. AN IMO It's component architecture is more mature than Angular 2 and superior to any MV* framework
3.3.3. Cons
3.3.3.1. It's not a framework
3.3.3.1.1. You need to decide on a whole bunch of different libraries to put together your pack
3.3.3.1.2. You need to write quite a lot of code to just get started
3.4. EmberJS (proposal)
3.4.1. Pros
3.4.1.1. 100% Convention over configuration
3.4.1.1.1. This means 0 project boilerplate - literally (see ember-cli)
3.4.1.1.2. Out of the box support for unit, integration & acceptance tests
3.4.1.1.3. Comes with predefined project structure (layer-oriented or feature-oriented [pods])
3.4.1.1.4. Adding components/features to the project is a breeze using built-in blueprints
3.4.1.1.5. Any part of the framework is extensible (very much like ASP MVC does)
3.4.1.1.6. Clear data flow through the application, based on well-defined layers
3.4.1.1.7. AN Sorry to disagree, but I believe convention-over-configuration is one of the worst paradigms to plague to development world in recent years.
3.4.1.2. An opinionated framework - with it's own API
3.4.1.2.1. AN Opinionated can be equally good or bad, depending on the opinion
3.4.1.3. Highly based on components (as in W3 standard)
3.4.1.4. Great documentation with big community (guides.emberjs.com)
3.4.1.4.1. AN Emberdocs, when I was considering it, we're one of the main reasons most people were avoiding it
3.4.1.5. Tons of community components via Ember Addons (emberobserver.com)
3.4.1.6. Uses React approach to rendering templates (smart model change detection)
3.4.1.7. Uses Handlebars templates which compile in a sourcetree (high rendering performance boost)
3.4.1.8. Has an extensible build pipeline
3.4.1.9. It's server API agnostic (it uses modifiable Serializers and Adapters to communicate with any type of data format the server might serve - mainly REST or JSONAPI)
3.4.1.10. Has a built-in ORM (Ember Data)
3.4.1.10.1. This means you never "have to" make an AJAX call manually - you just access the "store" and CRUD objects
3.4.1.11. Has a lightweight dependency injection system
3.4.1.12. Great Chrome Dev Tools plugin (Ember Inspector)
3.4.1.13. Write apps using ES2015
3.4.2. Cons
3.4.2.1. Steep/ish learning curve (not so much in later versions) - needs a committed team to work using latest practices
3.4.3. Notes
3.4.3.1. The framework's development has been fast lately, so some articles might be obsolete (at least those under version 2)
3.4.3.1.1. They have streamlined the release process with well-defined time releases
3.4.3.2. There's lots of meetups that discuss the achievements and road ahead (useful for seeing future updates)