There is no doubt that in the universe of Javascript frameworks right now React is clearly winning the popularity contest. A quick survey of npmcharts, which tracks downloads, for any single day in the month of December shows results similar to this:

The first Javascript framework I learned was React. The truth though is that React is not really a framework, per se. React is a library, albeit a powerful library, but it does not create the full MVC (Model-View-Controller) architecture for your application. It is basically the View of the MVC. Angular provides the full MVC architecture for your application, and as such functions as a true framework. However, having said that, people, including myself, treat React like a framework. The additional usage of middleware, such as Redux, further extends the functionality.

This past week I needed to learn Angular for a small project I was assigned. Through that process, after taking a first look at Angular, I have some reflections on React vs Angular, and also a big lesson to share. I hope these reflections are helpful for you as you deliberate on which approach might be better suited for your application’s needs.

First, the big lesson. Sharing where you made a mistake is not always easy, especially in a public forum, but all too often our Internet selves is a distillation of our lives into just the perfect moments. Real life and growth is through the mistakes as much as it is through the successes.

So, having said that, my big lesson is know which version you need to learn! Prior to the project start date, I spent a few days learning Angular, and I thought when the project began that while I was not an expert, I did have a grasp of it. I couldn’t have been more wrong. Without realizing it, I had spent the prior few days learning the first version of Angular assuming that newer versions would be similar to that. I found a curriculum I really liked and went with it. Well, that was a big mistake. Angular 2+ is very different than the first version. Like, practically an entirely different framework level of difference.

Big Lesson: Do your research on version changes of a technology before committing to learning a particular version.

Now on to the initial reflections on the differences:

Javascript in HTML or HTML in Javascript?

React introduced the world to JSX, which allows you to write HTML directly into your Javascript. Of course, as one would imagine, this takes some modifications to make work. For example, reserved keywords in Javascript need to be called something different in JSX so as not to conflict, like className for an HTML class. This allows you to create React components that take advantage of simple logic to render views to your users. You could deploy a ternary operator to display different data depending on the outcome of that check. JSX lets you do all of that from within the same file.

Within Angular 2 a developer takes advantage of directives that can be inserted directly into your HTML that represent different actions defined either in the core Angular code or custom written by you. For example, ngIf is a way to define a conditional check inside an HTML tag that you might use for creating alert messages if a form is not correctly filled out. Another common one for a form is ngSubmit that lets you define the Javascript function that gets called when a user submits the form.

How Opinionated Do You Want Your Framework To Be?

React because it is a library that simply provides the View for your application is not highly opinionated on your application’s structure. There are lots of best practices out there for how to structure your React application and I would recommend following them for both convention reasons and for scalability. Yet, you do not need to do so if you do not want to. It is highly recommended, for example, to separate out your components that manage state and the ones that are stateless. It is also a good idea to build code that is reusable throughout your application, but again you do not need to do these things if for some reason you don’t want to.

In my learning of Angular thus far I have discovered a highly opinionated framework. Both React and Angular are great at displaying errors that are helpful in moving your application forward and identifying where the issues are. However, in Angular when moving to compile the app to production mode with the helpful Angular CLI and ng build, a single error, even a small one that doesn’t impact the running of the application at all, will stop the build of the application. A quick Google search shows that this a source of frustration for many people.

However, you can see how this is also a good thing. If you are compiling your application for production you shouldn’t leave any errors! Yes and it is also true though there is a difference between should and could. In Angular you can’t, in React you shouldn’t but can.

Your Data: A One Way or Two Way Highway?

One of the first lessons you learn when you begin down the React journey is the immutability of data. Programming conventions like Flux and middleware like Redux implement one way data flow in your application. Whether you have one store of data or multiple stores, dispatchers or a dispatcher built into the store are questions about how you want to design your application, but what lies at the core is the idea that data flows in one direction. Whether you employ Object.assign or the spread operator in ES6 to update your state, what you are doing each time is creating a new state and not modifying your existing one.

Angular, on the other hand, is all about two way data binding. The ngOnChanges hook in HTML can watch for any changes in a user input to update the data of the application. The mutability of your application’s data can create a great deal of dynamism and flexibility. Yes, you can enforce immutability in Angular using things like Immutable.js or other strategies, but it is not inherent into the organizing philosophy of the framework. Mutable data makes tracking changes more challenging and can also have implications for performance, so it seems based on my research this week, more and more people are enforcing immutability of their data in their Angular applications as well.

Who Has The Steeper Learning Curve?

As mentioned above, my learning of Angular this past week was colored by my beginning with an older version that was, for the most part, no longer applicable to the current versions. However, putting that aside, Angular, in my experience, has a steeper learning curve initially than React while React is quicker to learn at the outset but takes more learning once you get going to use it well.

Due to the more opinionated nature of Angular and its stricter enforcement of its conventions, you need to commit more time at the outset to learning how to initially setup your Angular application. React, because it is largely not concerned with how you structure your application, takes less time initially to learn. That changes though once you get past the initial phases and begin thinking about not only how to get your application going, but how to do it well. Precisely because React is less structured initially, it requires more learning on how to optimally structure it down the road. So, in my estimation, Angular takes a larger investment of time initially while React takes a larger investment of time later once you are past the beginner stage.

Who Wins?

As one probably expected, the answer is it depends. It depends on what you are looking for, what your business requirements are, what kind of functionality you want out of the box and more. Both React and Angular have engaged worldwide communities surrounding them and both are supported by major industry leading companies so you can be assured that they will have long term shelf life.

It is clear that currently React is the more popular item, but popularity is not the sole determinant for application development. In the world of Javascript frameworks, going by popularity alone might mean that you end up switching every few weeks for the latest and greatest as the conveyer belt keeps on turning out new frameworks at rapid speed. I believe that either framework will serve a business or organization well.