For most developed countries, a strong bureaucracy (i.e. a well functioning state) came before democracy. The exception to this is the United States of America. This is the claim made by Yoshihiro Francis Fukuyama in his 2014 book Political Order and Political Decay.
Countries which developed well functioning states, such as the predecessors to the current German state, China and the United Kingdom did so well before they had adopted democracy, developing strong institutions as a result of external pressure such as war. In these pre-democratic states, the external pressures resulted in an incentive to build strong, merit-based, impersonal institutions to adequately respond to the threats. Then, with the increasing social mobilization that came about by the state-enabled growth of the industrial revolution, increased political participation was demanded by the newly economically empowered citizens. Thus the early transitions into democracy.
On the other hand, states where democracy was introduced before strong states and growing economies, state institutions became instruments to reward those who supported political candidates, through appointments within these institutions, or directed spending of the funds of these institutions towards the supporters. Thus, citizens are more incentivized to seek enrichment through political participation compared to building businesses on top of the foundation of an impersonal state.
Therefore, despite democracy being a good thing in itself, the contexts in which it was adopted had very differing effects, depending on the political maturity of the contexts. Similar to the Angular and React web frameworks (or libraries).
React offers a library to bind the DOM to a changing application state. It cares very little for how the state is managed or how the web application is constructed. React components receive properties, render the DOM according to how the developer has specified, and returns information through the callback functions. There are other libraries in the React community ecosystem that integrate with React to handle more parts of the application such as Redux and the React Router, but these are ancillary to the core React library.
Angular on the hand provides a complete opinionated framework for the creation of a web application, including binding the DOM to a changing state, making REST calls, management of state, URL routing, etc. Therefore, on creation of an Angular application, one can easily create a fully functional and complex web application.
A common complaint with users of Angular is its verbosity. To create a simple page, one requires an Angular module, a Component (with potentially 3 files), and a Routing module. All this scaffolding seems a bit much when compared to a React application which only requires the main html file, and one component. The simplicity and conciseness of React is definitely appealing when one wants to get up and running quickly.
Yet, just as democracy fares differently depending on the context it is adopted, so does Angular and React. There are three contextual factors I’ve seen that affect the success of the chosen framework: the previous experience of the team, the enforced standardisation within the team, and the size of the team.
The Previous Experience of the Team.
In large enterprises, where many developers have experience in building backend enterprise applications using statically typed languages such as C# or Java, the jump to React is a difficult one, requiring a different way of thinking that someone who has experience in functional JavaScript my be more accustomed to. This has resulted in inefficiently structured codebases, with every component connected to the Redux store, making it hard to refactor in order to simplify.
On the other hand, a team used to functional JavaScript may find the scaffolding and verbosity of Angular a bit much, as well as the specifying of types annoying (though not always necessary).
The Enforced Standardisation Within The Team
Angular provides a very opinionated way to write applications, and linting out of the box to test whether code being written adheres to the standards. This makes it easy for new developers to jump onto a project and ramp up quickly because they are already used to the way things are done.
React on the other hand doesn’t. And there are a multitude of ways to do everything, from making API calls, to structuring components, to state management. If a team doesn’t enforce a standard, with the automated checking of the adherence to that standard on the continuous integration server, then it will become increasingly difficult for developers to work on pieces of code that they have not previously worked on.
Size of the Team
Within smaller teams, communication between team members is a lot easier, allowing the team to agree and continuously improve a standard and approach much easier than on larger teams. On a larger team, communication between developers becomes a lot more difficult, requiring more on scaffolding and constraints as a means of communication, as Angular provides.
So which one is better? It depends. Yet, it is more a people decision than a technical decision.
Patrick Kayongo 