I’ve used AngularJS 1.x for 18 months on a greenfield internal project, and then used React + Redux for 6 months on a bigger commercial web project.  I’ve been interested to find strong parallels with other UI frameworks I’ve used in the past.

AngularJS 1.x

AngularJS 1.x was an excellent framework to build a modern single-page web-app.
In learning it I was struck by the similarity with WPF.  This rich client framework from Microsoft, along with its similar cousins Silverlight and WinRT, have some similar pros and cons.

Pro:

• clear separation of view/controller/service (WPF view/view-model/model)
• simple 2-way binding between view and data in the controller (WPF view-model)
• full, clear access to html/css/javascript for styling and behaviour (WPF gave much richer styling than earlier Windows UI tools)

Con:

• views/controllers could be nested, but were tightly coupled and not fully reusable (views were easy to reuse, but the controllers/view-models were not usually reusable as they had both view-specific and app-specific code)
• reusable extensions had to be written differently as separate Angular directives (WPF templates)
• learning curve for initial view/controller was smooth, but then there was a large jump in complexity to build reusable components or extensions

In both Angular and WPF the strong 2-way binding gave a clear code separation and design model to follow.
view -> user actions -> controller/viewmodel -> update model objects -> bound view fields automatically updated

In both Angular and WPF the initial start was great.  It was possible to build great single screens, with control over styling and behaviour with much richer user interaction than before.  But in scaling up and building a whole app, or building components for other developers to re-use, both were very frustrating.  The level of difficulty was suddenly much higher and it seemed like a completely different set of tools and knowledge was needed.
In Angular directives interact with your app and your data very differently than the views and controllers you created first, and in WPF templates worked differently than views/viewmodels.

React/Redux

React was a fun UI library to build growing, scalable web-apps.

In learning React I was struck with how similar it felt to server-side web frameworks.  All the way back to when PHP and JSP were new, the idea of an HTML template with embedded commands to include data have been common.  What’s changed since then is the structuring of code around these views, from embedded code in the view, to different ways of building action/controller classes that separated event-handling and data updates.  From early Java servlets, Struts actions to modern ASP MVC controllers, every language has a similar pattern to build web-apps with server-side separation of the view and the logic.  These all have the disadvantage of a browser page load and server round-trip, leading to today’s single-page apps.
React has the same model and has very quickly gone though a similar evolution of design models around the view templates, from code embedded in the same file as the view, to patterns/libraries like Flux or Redux to separate the event handling and updates to model data into a separate controller/store.
This has led to some similar pros and cons.

Pro:

• simple way to build templates to display data
• simple way to build reusable and scalable components
• full, clear access to html/css/javascript for styling and behaviour

Con:

• easy to mix code with the view, reducing reuse and maintainability

In React/Redux and server-side web the simple cycle of data/control flow gives a clear code separation and design model to follow.
view -> event -> dispatcher/router -> action/controller/reducer -> update model objects -> whole view regenerated

In React I found the learning curve much smoother than Angular.  It was quick to build your first view, but just as quick to build a reusable component as it used the same techniques.  One reason for this is that React didn’t try to do as much – React just does views.  So building a whole page or just a little part is the same.  This is similar to JSP or ASP.Net Razor, just the view design, which makes it simpler to compose and reuse them.
This gives a potential disadvantage too as people are free to abuse it and couple their view and logic all together, much like code-behind in VB6 or early JSP with pages of database access embedded directly in the markup.  But patterns like Flux and libraries like Redux have grown up giving a clear view/controller separation for React.  These easily give a simple way to cleanly separate and test your code, without making it harder to grow.

Contrast

AngularJS 1.x (and WPF) was easy for developers with existing C++, C# or Java skills to pick up initially, but hard for the same developers to progress in. 
React was easy both to start and to then scale.

I bring this up because as well as there being a large set of existing developers who could transition to using these tools, there is a large number of developers who will always only dabble with any UI technology.

There are many projects where the UI is targeted at an external customer or where the visualisation of the fuctionality is seen as the major part of the application.  In these cases the UI will have priority, either with dedicated UI developers hired for these skills or with developers and managers understanding that time to deeply understand the UI technology will give real benefits.  For these the time to understand the complexities of the UI framework more deeply will be greatly rewarded, and the framework should be chosen on its fit for the project.

But many projects don’t have this focus or this time.

There are many, many other projects where the UI is only seen as a minor part of the project.  Many internal company projects where far more work and attention is paid to the business logic and the data model than to the user interface.  On these projects the UI will be left to the same C++, C# and Java developers working on the back end.  They need to be able to switch into the UI code for short periods for one fix or one new feature.  They don’t have time to learn another complex framework just to add a button.  For these projects React with its smaller, consistent feature set to learn and scale with may be an advantage.

Either way developers might find comparing these new tools to previous generations helps them understand how to get the best from them.

Angular 2.x

All the above is based on my personal experience over the last 2 years.  I’m expecting to pick up Angular 2.x on a new project sometime soon as the web changes fast and it has become this year’s must-try framework.  I’m looking forward to exploring that too, how different from Angular 1.x is it and how much does it feel like other past frameworks.

Links

• AngularJS 1.x: https://angularjs.org/
• React: https://facebook.github.io/react/
• Redux: http://redux.js.org/
• Angular 2.x: https://angular.io/