Angular vs. React: A Tale of Two Philosophies

Angular and React are two of the most popular JavaScript frameworks for web development. Each espouses its own philosophy and boasts proponents who swear by one or the other. The goal of this series is not to promote either framework, but to provide an honest evaluation of each framework’s strengths and weaknesses to better equip developers to choose the one that best suits their goals and personal coding style.

In Part 1, we learned the role that JavaScript Frameworks play in web development, and explored our two frameworks’ features. In today’s follow-up, we’ll see how their differing philosophies can both enhance and hinder our coding efforts.

Isn’t React a UI Framework?

Right on the landing page, React touts itself as “a JavaScript library for building user interfaces”. What about state management, routing, data binding, and other important elements of a web application? That’s where the myriad of third-party libraries come in, for instance, Redux, React Router, or Helmet. These provide functionality such as component-based routing, project generation, form validation, dependency injection, and whatever else your application may require.

However, if you like to have most of what you need already in place, then Angular may be just your ticket. As a full-fledged framework, it usually does not require additional libraries. I will say that the applications that I develop do employ some additional libraries, most notably, RxJS. It’s a library for reactive programming using observables that makes it easier to compose asynchronous or callback-based code. There’s even a page in the Angular Docs dedicated to RxJS. There are plenty of other tasks made easier by enlisting various npm libraries.

Learning Curve

Angular is a fairly massive library. Coupled with the fact that it strongly dictates how to do things, learning all the concepts and methodologies associated with Angular will take a substantial amount of time and effort on your part and those of your teammates. Angular is complex, employing a lot of specialized syntax and intricate component management. Moreover, many complicated features are baked right into the framework core, which means that you can’t avoid learning and using them.

Then there’s TypeScript. Although it’s based on JavaScript, the strict type enforcement will have you scratching your head on a daily basis. In strict mode, the newest version forces you to declare whether or not a variable can be null or undefined. You’d be amazed how much that will complicate your coding efforts! Who knows what challenges future versions may bring? On the flip side, you may appreciate the extra protection afforded by the unforgiving type enforcement.

Performance Considerations

Depending on your user base and industry, application performance may be a crucial requirement for you. If that’s the case, React should probably be your top contender. React’s performance is greatly augmented thanks to the virtual DOM. Virtual DOM trees are built on server, thereby reducing the load on the browser. React also employs unidirectional data-binding so that bindings are not assigned watchers as in the case of Angular. The reduced processing running at all times helps lessen the burden on browsers.

As I can personally attest, in the case of complex and dynamic web apps, Angular’s performance tends to suffer. One culprit is its bidirectional data-binding. Each binding is assigned a watcher to track changes, and each iteration proceeds until all the watchers and associated values have been checked. As a result, the more bindings you have, the more watchers are created, and the more processor intensive the whole process becomes.

It’s not all bad news though; the most recent version of Angular has greatly improved its performance, to the point that the gap between it and React has almost been closed. The size of Angular applications has now become slightly smaller than that of comparable React apps as well.

Application Structure

Both rigid and complex, the structure of an Angular application is not well suited to novice developers. Unlike a lot of traditional programming languages like Java and C++, Angular is what you’d call component-based, whereby each component is typically split into four separate files:

1. a TypeScript (.ts) file that contains the structural logic of the component as well as the @Component directive that links to the other component files and service providers:

   @Component({
     selector: 'dashboard',
     templateUrl: 'dashboard.component.html',
     styleUrls: ['dashboard.component.css', 'dashboard.component.scss'],
     providers: [DashboardBroadcastService, DatePipe],
   })
   

2. an HTML template file that defines the view
3. a CSS file that governs the component’s appearance
4. a unit testing file

The philosophy behind Angular’s component-based architecture is that components act like reusable widgets that you can plug into your applications where ever you may need them.

In stark contrast, React’s motto is that there is no “right” structure for a React application. Hence, React developers are free to choose the best structure for their apps. But just as great power comes with great responsibility, so does great freedom. You and your team will have to design the app structure at the beginning of the project, making the start-up process a longer one. Moreover, poor design choices could come back to bite you, depending on your proficiency in such things.

While the architecture of a React app is also component-based, React components, which are rendered with React DOM library, may be produced in one of two ways:

1. functional (with a function that returns JSX):

   function ShowProperty(props){
     return <div>The value of {props.name} is {props.value}</div>
   }
   

2. class-based (with ES6 classes):

   class ShowProperty extends React.Component {
   render() {
     return <h1>The value of {props.name} is {props.value}</h1>;
   }
   

Not to mention, it’s difficult to be overly prescriptive when React offers only the View layer, while Models and Controllers are added via external third-party libraries.

Conclusion

In the second part of this Angular vs. React series, we saw how their differing philosophies can both enhance and hinder our coding efforts. While you may feel that you now have enough to go on, don’t make any hasty decisions! There are still factors to consider yet…