It is an age-old question, and age-old is used loosely here considering how blazingly fast the front-end technology landscape changes. Should we use React, Angular 4, Vue.js, Ember.js, Aurelia? Is there something new and better now that we should consider?

Here at The Remi Group, we are tasked with building a series of new tools to facilitate the business operations of the company. Due to the complex nature of the domain, the front-end applications will need to be robust, with complex workflows. We wanted to choose, very carefully, a front-end tech stack that would support the business for years to come.

For the most part, everyone agreed we should choose between Angular 4 and React. This was mostly due to the fact that these were the two technologies that the team is most familiar with, and the cost of ramping up to a new tool-set did not outweigh the benefits provided by the tool-set. After all, software engineering is all about trade-offs. Speed-to-market is the most important priority, but long-term viability is a close second. These two factors were in the forefront of our thought process when we made our decision.

We got together to discuss the pros and cons of both React and Angular 4 to determine which one we should go with. It turned out to be a much closer race than anyone who is strongly opinionated (aren’t we all) would be comfortable with.

This is why they’re hot

Both Angular 4 and React have huge benefits as front-end technologies. It’s the reason this debate has been raging since React stormed onto the scene to replace AngularJS.

Both React and Angular 4 support TypeScript as well as native JavaScript. We collaboratively agreed that TypeScript brings huge benefits by adding compile-time checking to JavaScript, significantly reducing the development / debug cycle for developers.

React and Angular 4 both allow for great modularity by fully supporting componentization.

Both are very heavily documented. Google has even provided a comprehensive style-guide on how developers should structure apps built with Angular 4.

This is about where the similar benefits (that we care about) end between the two technologies. This is all well and good, but it only speaks to why they are both awesome.

The nitty-gritty

What really made things interesting were the individual strengths and weaknesses of each technology.

Angular 4

Angular 4 was my personal favorite in the debate. Mainly because I am an OOP programmer, and it just feels good. This is one of its strengths; it feels natural to OOP programmers because of its built-in dependency injection system. We have a team of primarily C# engineers, which makes picking up Angular 4, with TypeScript, slightly faster at first.

Angular 4 is a framework, bringing with it everything needed to develop a production-ready application. To some, this may be seen as a drawback, but it appeals to the speed-to-market priority for us by removing the need to decide which library to use for certain functionalities. Because everything is already provided, we can just wire up and go.

Lastly, Angular 4 gives the developer the ability to use a store state management pattern, or built-in state management. Using the provided DI system, engineers can scope services at varying levels of the application. They can be scoped at the component or application level. That is, if you need a new state for a given component, scope its service(s) at the component level as opposed to the application level and vice-versa for application wide state.

While these are all very compelling reasons to adopt Angular 4, there were some drawbacks that we had to consider before making the decision.

There is a lot of noise in the development community around Angular being a dead or dying technology. While I do not believe this in the least, I do think that the public is very hesitant to adopt Angular 4 after being burnt by abandonment on AngularJS. There was no clear upgrade path from AngularJS to Angular 2, leaving many a developer scorned. In fact, Google has a long track record of abandoning endeavors.

For these reasons, there has not been widespread adoption of Angular 4. This is certainly a drawback, because it means there won’t be as many helpful blog posts, Stack Overflow questions, and Quora answers on topics. This leaves pioneers on their own to figure out how to implement edge case x, y, and z, as well as detracts from our primary priority: speed-to-market.

Lastly, one of my biggest gripes about Angular is the need to learn a templating language. Angular 4 is much simpler than AngularJS was, but it is a templating language none-the-less.

React

A lot of React’s benefits directly counter some of Angular’s drawbacks. For example, React uses JSX as opposed to a templating language. At first, JSX may seem like a violation of separation of concerns. It seems like we would combine view and controller logic in a single file, but that isn’t the case. React allows for separating your logic and views into separate components. This results in dumb view components and smart logic components, and because there is no templating language, developers only need to know JavaScript, or TypeScript in our case.

React is developed and used by Facebook. There is little worry that React will be abandoned in the same manner that AngularJS was. As you may already know, Facebook is currently working on a complete rewrite of React called React Fiber, and it will be backwards compatible. Angry eyes at you AngularJS.

Because of its large popularity, React has huge community support. There is no shortage of third party libraries for React. If you need it, chances are someone has built it already. This is how programming should be :). For us, this plays right into our speed-to-market and long-term viability priorities. React has lived in the wild, is battle-tested, and has stood the test of time. There has never been a better time to be a React developer than right now.

There are, however, a few drawbacks for us in choosing React. React has a steep learning curve when combined with Redux. The idea of a one-way data flow, single source of truth store is a new one. The best advice I received regarding learning React is to focus on just learning React. Too often developers try to pick up both React and Redux at the same time. This complicates both concepts. If you focus on one, it’s much simpler to wrap your head around. Because of these new patterns, React doesn’t feel like a natural transition for OOP developers. This makes the learning curve slightly steeper than Angular 4.

React takes the lead

Hopefully by now you can see how the race to choosing React was a close one, but React is the clear winner for us. It boils down to Angular 4 requiring the learning of a templating language and its lack of popularity and adoption by the JavaScript community. Realistically, learning the templating language wasn’t a major factor in our decision. The thing that weighed most was the worry that Angular 4 could be rewritten in 3 years without a clear or supported upgrade path, or that it may lack adoption for a long time.

Don’t get me wrong, we are super smart engineers who love playing with new technology, but at the end of the day, delivering value to the business is our core goal.