As this is a very contentious topic within the development community this will be a continually changing blog as we learn more and receive feedback. I also wanted to put out a couple of qualifiers so everyone understands where we’re coming from.
Our Background
Our company is headed by my co-founder and CTO, Ryan Campbell, a software architect with 18 years of experience, the last 10 years in large enterprises. He was already familiar with Angular 1 when we decided to use Angular 2. However, we also built an app in React before deciding on Angular. More on that below.
We also truly believe that both Angular and React are great choices and have allowed some amazing products (React: Messenger and Angular: healthcare.gov) to build and grow on top of them. The decision is much more situational, based on the specific project, the team, and their experiences/preferences. The goal of this article is to walk you through our thought process and shed light on some findings we had through our journey to picking Angular.
Here’s a quick overview of the two technologies:
Angular 2 — backed by Google, is the newest JS (javascript) framework to takeoff.
Key characteristics:
- Opinionated — there is an ‘angular way’ of writing things
- Typescript is commonly used for efficiency
- More boilerplates and re-usable components backed by Google
React — backed by Facebook, is a library within the JS language, not a framework.
Key characteristics:
- Open — React allows the developer a lot more flexibility and latitude
- More freedom of choice
- Updates and changes more frequently
Library vs. Framework
The biggest difference is how they are structured. React is a library and angular is a framework. Defined below:
- Library: I am going to use the React library so now I have to decide on all the other supporting libraries I’m going to use for routing, model management, and build tools.
- Framework: I am going to use Angular 2, let’s start building an app the way Angular 2 says so.
Therefore, we aren’t comparing Angular 2 with standalone React, we are comparing to React plus all of the additional packages required to get functionality parity with Angular 2 (something like React + Redux + React router + Babel).
Our React Experience
When we built an app in React we REALLY enjoyed the library. We were excited by all of the possibilities and the upfront learning was much lower than Angular. When we started building our first React Native app our team had limited experience with React and the ecosystem was much newer.
We knew we could use React to quickly create an MVP which was important as this project had a very short timeline. Our first step was to get the project setup which meant finding the correct supporting tools to integrate. This is where we made a major mistake. We chose to use @exponent/ex-navigator a router library which seemed to have good support and was developed by exponentjs, who are known for quality tools in the React ecosystem.
We started fleshing out the prototype of the app and it wasn’t until we started trying to pass data around the app that we noticed this router was nonfunctional and abandoned. You had to mutate the state to pass the it through the navigator, that is the #1 thing you shouldn’t do in a modern React app.
This experience left us disappointed with building an app with React. React itself was amazing, there was not one major complaint about React itself within our team. Unfortunately the same could not be said about the supporting libraries we chose. But this was our own mistake, and something you could possibly avoid if you are more careful about your initial choices. However, there will always be the risk of a library you are actively using being abandoned.
Our Angular 2 Experience:
We’ve built multiple apps in Angular. All the parts within the Angular 2 framework, including the high level architecture are backed by Google. Which has really helped get everyone on the same page and standardize large teams, but it has also caused some issues.
For starters, a lot of thought went into Angular 2 and each of the modules it provides. It feels like a high quality framework that an enterprise developer would be familiar with. It’s pushing the boundaries of what’s expected out of a web based application framework. We’ve definitely come a long way from developing apps with jQuery or even Backbone. Our team enjoys the Angular 2 dependency injector, built-in ready-to-use HTTP module built using the reactive programming observable pattern, and a well thought-out Angular 2 upgrader allows for large projects to be moved to Angular 2 piece by piece.
The only downside I’ve experienced with all that is much of the framework is still yet to be documented. The Angular documentation so far is high quality, but only scratches the surface for many of the Angular 2 modules. As a team we’ve gotten around that by digging into the Angular 2 source code and sharing our knowledge to become experts on how everything works together.
In general, we’re very impressed with Angular 2 and it is our framework of choice. We’ve been able to complete features easier than with past frameworks. TypeScript, the documented best practices, and the Angular 2 architecture have made building applications enjoyable. We’re able to take our knowledge of OOP, design patterns, and best practice architecture and apply it to the web.
Why is Angular a better fit?
Our clients are mainly large enterprises looking to benefit from open source. When choosing software, they care about reducing risk via:
- Technology consistency
- Community support
- Clear best practices
- Minimal unknowns
They have millions of users and millions or billions of dollars that are impacted by the software they manage. These decisions are crucial and sometimes even life and death.
They also stick with a technology for a long time and require consistency, clear best practice, and minimal unknowns.
Technology risk has to be reduced to allow enterprises to harness the power of open source and reap the benefits from the amazing work the open source community has provided.
How do enterprises quantify risk?
Enterprise companies quantify risk in three different areas; support, community and risk. When comparing React and Angular 2 in those areas, in terms of what enterprises are looking for, you can get a better sense of why Angular 2 benefits them.
Support around the technology
React — Discontinues support fast, staying updated is difficult
Angular 2 — Google’s public goal: No more breaking changes after release 2.0
Availability for hiring
React
- Large community following, will have big talent pool.
- Less standardization/more training — due to the openness of the technology developers will build in their own way.
Angular
- Large community following, will have big talent pool.
- Simple onboarding — developers will follow similar best practices.
- Standardized — Google is releasing best practices on how to write using their framework for developers to follow.
Potential abandonment by backer/creator
React
- Support — Highly supported, growing community.
- Reliance on others — High. Library supported by Facebook but not the other pieces required which are built by 3rd parties.
Angular
- Support — Highly supported, growing community.
- Reliance on others — Holistically supported. Minimal reliance on others other than Google and their development team.
In Conclusion
Based on our experience developing with both React and Angular 2, and the needs of our clients, we’ve decided to go with Angular. That doesn’t mean we aren’t open to new options, but right now, for our customers, Angular fits their needs and we are thrilled with the results.
We know there are a lot of opinions on this subject so please feel free to let us know what you picked and why. We’ll be diving deeper into debugging and development tools within both of these frameworks so stayed tuned for updates.
