Why I moved from angular 1.x to React (not angular 2.x)

Gagan Sharma
Curofy Engineering
4 min readSep 4, 2017

--

At Curofy - Medical Discussion Platform, we recently launched web client for the users. Our internal team’s platform was built on angular 1.5. After using it for 8 months. Internal team starting to have certain problems related with huge data manipulations and various admin tasks. So I tried to look for some other frameworks. The two options which I found was either to use Angular 2 or React.

Angular 2 and React both of them were different from Angular 1 in many ways, but that was one of the problem. The main thing I didn’t like and I still don’t like about angular 2 is Typescript. I know Angular 2 can be used with Javascript but again, from what I understand using pure javascript with Angular 2 is not the ideal way you should be using Angular 2. In any case using TypeScript meant rewriting of the project and learning TypeScript along with Angular 2 was a waste of time with only 1 resource and less time to develop. I didn’t chose TypeScript because defining a simple object was more complicated to do on TypeScript. I still remember how easy to work with Angular 1 was, it certainly had it’s own problems, but it was nice to work with it compared to other frameworks.

React

Then the obvious choice was React, because well, everybody is doing it and the ones who are not, are talking about it. So that was the option, certainly knowing that Facebook is behind it, helps. However, React itself is not a framework, you need to add extra stuff to make it shine. So React with Flux architecture made it possible.

Decision process

I first started to define what our decision points were going to be, I knew the our web client would be need to have the following:

  1. It should be stable
  2. Backed by strong community
  3. Good Documentation, lots of questions and solution on StackOverflow
  4. Easy to learn
  5. Integration with Bootstrap
  6. It should allow us to reuse the code
  7. Coding speed
  8. Should be component based
  9. Data Handling

I was surprised by how far I got with ReactJS in a couple of days. I got a good understanding of the basic concepts of ReactJS, but most importantly I really enjoyed the experience of writing code with it and I felt, I was doing it faster than Angular.

With React along with Flux, a simple way of architecture that complements React and the concept of Unidirectional Data Flow.

Flux is probably better explained by explaining its individual components:

  • Actions — Helper methods that facilitate passing data to the Dispatcher
  • Dispatcher — Receives actions and broadcasts payloads to registered callbacks
  • Stores — Containers for application state & logic that have callbacks registered to the dispatcher
  • Controller Views — React Components that grab the state from Stores and pass it down via props to child components.
Flux Flow

Component based approach

Component based approach really helped and develop the web client faster than Angular. A React component can be thought of simply as a function that returns elements. This functional approach is very natural to Javascript developers. Data in, elements out(simple). If you have an array of things, you can simply map them to a list of elements. If you’d like to exclude some of those items, you can just use filter on that array and map the result to some elements. This approach is complementary to Javascript’s strengths.

Size Matters

Now lets cut to the chase and discuss about yet another important aspect for deciding frontend framework for your apps.

Angular 1 :143k

Angular 2: 766k

React 15.3.0 + React DOM: 43k

that’s a lot of numbers, At the very first glance, it makes Angular 2 a poor choice of contender.

Conclusion

Angular 1 has been there for quite a long time and since the launch of ReactJS, React seems to adapt to the new web standards way earlier than Angular. Angular 2 has come. I have enjoyed working with ReactJS more over AngularJS. So, lets put an end to this discussion. As per me, concluding that ReactJS is more powerful contender for choosing frontend framework won’t be wrong. Though, definitely learning isn’t harmful in any way. You can always learn and come out with a mixture of good features from both the frameworks and have the best of both worlds.

Thank You! Comments most welcome.

--

--

Gagan Sharma
Curofy Engineering

"Frontend Engineer " RivalSystems, ClearTax, Curofy .IIIT Allahabad Alum