We Write Code logo

Two of the hottest frontend technologies to emerge from the last decade are the Angular framework and the ReactJS library. Before going any further, it is important to understand the differences between the concepts of a framework and a library. 

A framework enforces the workflow by defining a template that the developer expands on to build their application. To imagine this, it’s easy to think about game development and the use of prebuilt game engines. Developers could create their own game engine from scratch, but such a task is difficult, would require much time, and has already been done. Many small and large studios alike instead opt to use frameworks such as Unity or Unreal Engine to save time and money — the stipulation being that developers are restricted to the workflow imposed by the engines and using them in the way they were built to be used. Angular is comparable to Unity. The “engine” has already been built, now it is up to the developer to use the methods and tools in place to expand and create their application. 

A library is more akin to building blocks, imported and assembled piece by piece as the developer sees fit. It is impossible to use Angular without being aware of the skeleton you are working inside, where this is not true of React. By including the React scripts, you can add React components to any HTML page without much overhead.

As a framework, Angular provides many functionalities by default. Dependency injection, routing, and form handling are a few examples. Using React, you often must rely on separate libraries or custom logic to deliver these functionalities. This means that React is leaner, allowing the developer to add only the dependencies they need. However, functionalities built into the Angular framework can often be considered stable, whereas published libraries can sometimes be outdated, incompatible with other libraries, or introduce bugs into your application. 

There were many obvious differences I encountered when transitioning between the two technologies. As a developer who first learned React before moving on to Angular, I felt better equipped to handle the learning curve of Angular, which can be significantly higher due to it being an all-encompassing framework. Here are a couple thoughts on just a few of the differences I experienced.

Typescript is standardized in Angular. Coming from React, where Typescript had to be explicitly added, having Typescript available by default is a major time saver and has prevented many common mistakes. Loosely typed languages such as Javascript are fun and liberating, until the wrong type is accidentally reduced into your application state, causing obscure bugs that may take hours to track down. Also, Typescript paired with a good editor (I use Visual Studio Code) is extremely useful, as it enables autocomplete suggestions for object properties and methods that are standard in most class based object oriented languages. 

Dependency injection is a design pattern that is not unique to Angular, but was a novel concept to me. I had little or no experience with the design pattern, but after becoming more familiar with it and using it in several applications, it has become a powerful tool for separating business logic from components and sharing services among components. It is invaluable in testing, due to the ability to provide fake, mocked versions of the dependencies or services.

Observables were also a concept I had little exposure to. In React, I was accustomed to promises being discarded after being resolved, but observables in Angular taught me about the prospect of asynchronously being dealt a stream of data over any period of time. Observables can be a complicated subject to new developers, but once I finally came to grips with them, as well as using RxJS (the Reactive Extensions for JavaScript library) to control the stream of data, and learning about the side effects of not unsubscribing from them (memory leaks), they opened up many possibilities.

Are you a developer who has used both the Angular and React technologies? Share your experiences—both good and —with us at hello@wewritecode.com, or giving us a shoutout on Twitter, @wewritecode, or Facebook, @WeWriteCodeDSM.