Choosing a Javascript framework for NewOrbit

Get Started. It's Free
or sign up with your email address
Choosing a Javascript framework for NewOrbit by Mind Map: Choosing a Javascript framework for NewOrbit

1. Decision criteria

1.1. Enables clear division of labour between dev and UI devs -JM

1.1.1. Perhaps allows for easy division of work between devs and UI devs

1.2. Low barrier to entry -JM

1.2.1. Smooth learning curve if possible and some idea of how to up skill new people and UI devs quickly

1.3. Make it fast to develop the "crud" that makes up 80% of most applications

1.4. Enable us to have consistent approaches across projects, to facilitate moving team members with minimal pain

1.5. Enable us to automate "the boring bits"

1.6. Good community support

1.7. Viable long-term future

1.8. Explicitly not a decision criteria

1.8.1. It doesn't have to be the fastest or most memory efficient - it just have to be Good Enough

1.9. Attractive to potential recruits

2. Contenders

2.1. Aurelia

2.1.1. Notes It has a paid support plan which may be good or bad In terms of framework/non-framework, I'd put Aurelia somewhere between React and Angular It feels more light-weight It has more obvious extension points It is explicitly designed to bring in stuff from other frameworks when you want Watch the 30 minute video on to get a good overview

2.1.2. Pros Favours convention over configuration 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 Fun Not if you hate MV* frameworks AN Commercial add-on packs to be available under support Controls Mobile controls Very extensible AN More so than other frameworks? It's a framework AN More so than other frameworks?

2.1.3. Cons Less mainstream Less support from other libraries/frameworks AN Much smaller talent pool will want to work with this No support for Foundation Zurb for apps, for example Mobile development less streamlined at this point No support from Ionic - though that may change Can publish with Cordova Commercial add-on pack with mobile controls AN Developing paid option called Aurelia Interface It's a framework AN Commercial 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.

2.2. Angular 2.0

2.2.1. Notes The fact that we currently use Angular 1.0 is irrelevant Upgrading is not obvious It is different enough that we'd have to re-train anyway 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

2.2.2. Pros It's a framework Very wide community support Everything works with Angular Ionic Foundation Zurb Etc Easy to hire for Though not convinced that really matters - it's more of a recruiter argument :) AN No it matters Good story for mobile development with things like Ionic that just make it easy Very comprehensive framework AN Has abandoned MV* and moved to a component-based model like React.

2.2.3. Cons It's a framework Favours configuration over convention Very configuration heavy Irritating need to specify dependencies in what feels like unnatural places Maybe extensible but I suspect it's not as easy - please correct me? AN Why would it not be? Not fun (at least to me) AN Perhaps, but what is not fun is cleaning up or working with the mess of most apps built on MV* frameworks Maybe personal taste but templating pattern is horrible confusing goes against html conventions too different to angular 1.0 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.

2.3. React

2.3.1. Notes

2.3.2. Pros It's not a framework AN Agreed Does ReactNative mean mobile is easier? Is it even relevant or is it something quite different? AN Easier? That is a very overloaded word. Less costly. More maintainable, more customizable, more performant, Yes. (can be) very fast Extremely flexible Fun AN IMO It's component architecture is more mature than Angular 2 and superior to any MV* framework

2.3.3. Cons It's not a framework You need to decide on a whole bunch of different libraries to put together your pack You need to write quite  a lot of code to just get started

2.4. EmberJS (proposal)

2.4.1. Pros 100% Convention over configuration This means 0 project boilerplate - literally (see ember-cli) Out of the box support for unit, integration & acceptance tests Comes with predefined project structure (layer-oriented or feature-oriented [pods]) Adding components/features to the project is a breeze using built-in blueprints Any part of the framework is extensible (very much like ASP MVC does) Clear data flow through the application, based on well-defined layers AN Sorry to disagree, but I believe convention-over-configuration is one of the worst paradigms to plague to development world in recent years. An opinionated framework - with it's own API AN Opinionated can be equally good or bad, depending on the opinion Highly based on components (as in W3 standard) Great documentation with big community ( AN Emberdocs, when I was considering it, we're one of the main reasons most people were avoiding it Tons of community components via Ember Addons ( Uses React approach to rendering templates (smart model change detection) Uses Handlebars templates which compile in a sourcetree (high rendering performance boost) Has an extensible build pipeline 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) Has a built-in ORM (Ember Data) This means you never "have to" make an AJAX call manually - you just access the "store" and CRUD objects Has a lightweight dependency injection system Great Chrome Dev Tools plugin (Ember Inspector) Write apps using ES2015

2.4.2. Cons Steep/ish learning curve (not so much in later versions) - needs a committed team to work using latest practices

2.4.3. Notes The framework's development has been fast lately, so some articles might be obsolete (at least those under version 2) They have streamlined the release process with well-defined time releases There's lots of meetups that discuss the achievements and road ahead (useful for seeing future updates)

3. Interested people

3.1. James M

3.2. Frans

3.3. Thomas Sileghem

3.4. Aaron

3.5. Mo

3.6. Phil

3.7. Henry

3.8. Ayyaaz

3.9. Andi

3.10. Damo

3.11. Tom H