Angular2 or React in the business environment
In 2015 and 2016, React was at the top of front end libraries for creating reusable components. AngularJS (Angular 1) was being slowly left behind; the Google team after 5 years of development learned from the users and came out with Angular 2. The framework was rewritten completely and it really is an amazing accomplishment.
As a software architect, a key task of my job is to evaluate the current and future tools, frameworks and libraries out there and see if one of more could potentially be a fit for the development team. As you probably know, they are a lot of articles comparing both React and Angular 2. As a user of both, I want to share with you my findings. One thing I want you to remember however: to really have a good understanding of those 2, try them! You will have a much and deeper understanding of the concepts and what everyone is talking about in their articles.
In order to give a fair evaluation, it was ideal to have a table comparison with certain points to compare them both.
| React | Angular 2 | |||||
| Type | Library | Framework | ||||
| React and Angular 2 can be described as same same but different. React focuses on the view component of things, while Angular 2 focuses on the MVC. In React, you have to build your MVC and everything that goes around it such as Routing and HTTP the way you see it fit. You can use any 3rd party library you wish to accomplish that. In Angular 2, the framework is opinionated; this means that they kind of force you to build things in a certain way. One advantage of Angular 2 versus React in this category is the fact that since Angular 2 is framework, the core components such as Routing, HTTP are already built in and are managed and updated by 1 party. React being a library allows you to pick and choose and this can have certain unpleasant effect. Consider a library that is vastly used in your application but for some reason the bugs are not fixed and the library is not longer maintained. You now face the following dilemmas: either you fork the library and fix the bugs yourself or you change the library completely. |
||||||
| Language | JavaScript | TypeScript | ||||
| Both have excellent debugging in Chrome (breakpoints). Both use ES6. TypeScript can be favored by individuals who like to have their language typed as this can save them some time debugging as some errors can be caught at compile time or by some who do not like JavaScript way of not having things typed. If you have always worked in pure JS, then you see no use for TypeScript as this may slow you down. | ||||||
| Debugging | More explicit | Less explicit | ||||
| In React, the error messages at runtime are more explicit. It really pin points you to the exact line when things are not going your way. Certain decisions were taken by the Angular team to not display an error/exception for certain behaviors which is totally understandable and this is a choice of the team. | ||||||
| Separation of HTML | HTML in JSX | HTML inline or in a template file | ||||
| Components in React are in JSX (JavaScript eXtensible). The HTML is directly into the JSX file in the render method. You also obviously can embed other React component in there. Since React is not opinionated, and the JSX can be embed, it can be harder for one to understand all the pieces of a component if it’s broken in many pieces. In Angular 2, the HTML is directly inline or in a template html file. The view is well separated from the Controller. In either or, the architecture or the components should be well thought out before splitting. If the components are broken in too many pieces, it can be hard to see the big picture when trying to understand the flow. |
||||||
| Templating | Using JavaScript functions/loops | Using directives | ||||
| It’s a bit easier to write repetitive stuff in Angular (as it always has been) then in React. The following example will show you why: React:
Angular:
Note that this is taken from a vanilla install. There is a library for React that does this |
||||||
| Flow | One way / Uni-directional binding | Two way/Bi-directional binding | ||||
| React flow is one way. That is your data is propagated down to the last layer of your view components. If you need 2 way binding you need to implement that. | ||||||
| Size | Smaller | Bigger | ||||
| React since it is a library is smaller in terms of size. Angular 2 is bigger as it includes all the modules to make it a framework. | ||||||
| Setup/use | Easier | Medium | ||||
| React can easily be setup and one can use their existing JavaScript skills with a bit of JSX to build a component. A user wanting to start with Angular 2 has to learn TypeScript and understand all the modules and components to build his application. However, I am not talking about adding libraries(redux/flux / react-router / etc…) to React to enhance its use. This can lead to a learning curve to understand how all the pieces work together | ||||||
As you can see, both have their strength and their weaknesses.
Okay, so how do I convince my manager to use either or?
That is the money question. React and Angular 2 do the same thing at the end of the day. They will render and make your Single Page Application (SPA) amazing! They both have a huge user base and they are both still being actively developed. It really comes down to the taste of the developers and how they believe one will be able to either solve certain of their problems better than the other or help them develop faster. If your manager sees that you want to work with a certain technology and believes in you, he will give you tools to be able to do so.
