When an Angular Developer Starts Coding in React – Read my Story

Photo of Karol Ścipniak

Karol Ścipniak

Nov 23, 2017 • 10 min read

I really like Angular! At the time most of the well-written websites were MVC applications, Angular 1 was a huge revelation to me Yes, there were older frontend frameworks such as Backbone, but Angular was the first one that made a real difference.

I could compare it to the first iPhone – there had been ideas, there had been attempts too, but finally, someone made it just right. Over several years, I did many projects using Angular or Ionic, and when the time came, I switched to Angular 2, which was even better in my opinion. Those days, as the frontend part of my developer’s stack, Angular was safe to me and provided a comfort zone.

For some time, I heard voices from everywhere praising React up in heavens. I like to get to know new languages and frameworks – almost every one of them is somehow unique and adds something new to the way I think about creating applications. React seemed to be interesting to me, but … there were two “buts”, actually. First, in my perception, React wasn’t very different to Angular – I heard that it was faster, cleaner and better overall, but I didn’t get the hype. The second “but” was the apprehension about my further career: I had good commercial experience in Angular, and starting programming in React would completely reset my experience to a job seeker’s point of view. Is it really a risk worth taking?

Some people say that life is a box of chocolates, and it can sometimes really surprise you. It happened once that I was looking for a new long-term remote job. I found a “frontend developer” job ad at Netguru that seemed to be very interesting to me. Everything was indicating that it will be a good match, and then came the conversation about the technology stack. During this step of my recruitment process, Netguru’s Technology Leader, Kuba, gave me a very interesting offer: “We really want you onboard but currently, we do not have any Angular projects, and you would have to learn React from scratch by working on one of our current projects – are you OK with this?”

I was.

Before we start, there is one thing I need to say. This post and my conclusions derive from my subjective observations and experiences I made during my “Angular to React” journey. It’s definitely not the ultimate truth, but based on conversations with other devs who migrated to React, I can say we share a lot of the experiences. If you are still dithering whether to learn (or not to learn) React, this article will help you to make the final decision.

The story starts with my first day at work – it was also my very first serious contact with React. Let the game begin!

Day 1 – The hype:

  • There are a lot of tutorials for all levels of expertise. Every site with online courses has a React tutorial – even Microsoft has its own.

  • My current company has a very well developed React section in its private wiki resources. There are tons of materials, articles and best practices. Nice!

  • First project overview with my teammate, Michał. I like the fact that there are no complicated functions and the code structure is rather flat. The project is pretty big, but not overwhelming. Everything seems to be in the right place.

  • Components are a wonderful thing. I’m not surprised that the new Angular somehow copied this solution.

  • React is described as a framework written in a declarative manner. From the very ancient past, when I discovered the LINQ data query library, I’ve been a huge fan of declarative/functional programming, and I am really curious how it will work with React.

  • JSX fits me definitely better than Angular templates. It is more elegant with its single brackets, has better code analysis and cleaner variable binding. You don’t have to worry about how many brackets or parentheses to use. Comparing to this, the solution in Angular 1.x is less intuitive and the one in Angular 2.x is too complicated.

  • I have found an interesting site. It was created especially for Angular developers like me. It explains several React conceptions using a comparison to the Angular solutions resolving similar problem. There are not so many articles in there, but the ones that were there were very helpful to me.

  • After reading several tutorials, I can say that they are pretty comprehensible, the learning curve is not that steep.

Day 2 – The Good, the Bad, and the Ugly:

  • The learning curve is steeper than I thought. It’s definitely more difficult than Angular 1.x and similar to Angular 2.x (for those who don’t know the first Angular). Adding a simple checkbox to an existing redux-form, while preserving the correct flow requires more effort than I thought – component, action, the “connect()” function and reducer – you have to go through them all.

  • I miss TypeScript: auto imports, intellisense, type checking. VS Code helps a lot with ES6 code (it even has some type definitions for React elements), but it’s still not the same. Some structures of TS, such as interfaces for data shape or enums for defining action types, would be very helpful.

  • It’s not an uncommon thing to pass action or variable names as a string. I really don’t like this. I really don’t.

  • Switching between corresponding components, consts, actions, and reducers is cumbersome at times. It would be great if there was a plugin that would simplify it, like in Angular 2.x.

  • They weren’t lying. React is really more like a library than a framework. The library support and its integration with the code editor aren’t so great – unlike in Angular, where the feeling was similar to Java or .Net environments. React does not provide its own solution for e.g. API requests or routing – you have to choose one of the many existing libraries.

  • I am mostly complaining, but there are good things too! The declarative way of programming in case of this framework isn’t just an attractive catchphrase. Unidirectional data flow, immutability and the use of pure functions as the main principles of React work really great. Many say that this is the future of programming, and I just can’t disagree.

  • Thanks to this article. I finally got how the redux “connect” function works. It’s great.

Day 3 – Test‘em all!

  • The time has come to write tests for the first React components I created over the previous two days. Declarative programming does a perfect job here. Testing functional-style components is just as simple as testing functions without side effects. I also like the idea of shallow rendering. I especially enjoy snapshots, fast “regression” tests with no need for time-consuming real rendering of the whole component.

Day 4 – “Do what thou wilt” ...they said
  • React is a very expressive and flexible framework, and I think it’s one of the reasons why developers like it so much. You can resolve a problem in many ways that will be correct and efficient. In my opinion, React utilizes a developer’s programming skills much more than Angular.

  • Unfortunately, the expressiveness also has a darker side: when there’s no “best” convention for solving given problem, and developers create their own solutions, the less experienced developers can create code that is of poor quality or hard to maintain.

  • Sometimes, you have to use dirty hacks in React. For instance, calling onFocus on an inner element is done via a named reference – this pattern is a negation of the functionally oriented nature of React and would rather fit Angular. Think what would happen if we made that reference to an element from an outer library, and in the next implementation, that component will be written as functional one? Dirty hacks are never good for maintainability.

Day 5 – The Goodfellas

  • The React’s community is very big and creative. There is always a person with some great idea that can make the experience of programming in React even better. It’s not only just “yet another select input library” but often a completely new and, most importantly, better convention of solving old problems.

Next days and weeks – The road goes ever on
  • The more I get know React, the more I like it. I think that the key to learning React is to grasp some main concepts like flux/redux, unidirectional data flow or the redux connect() method. Once you understand them, everything will become much, much easier.

  • The learning curve is different than in Angular (quite easy to start but hard to master). In the beginning, you have to make a greater effort to achieve the same result, but later, the learning curve becomes definitely more linear. You’ll learn new things in a natural way, and at some point, you will realize that making the project more complex does not necessarily mean that it will be a lot more difficult to understand and maintain.

  • I’ve created a side project from Microsoft’s “Typescript React Starter” seed. The integration between React and TypeScript is really good, and it can be a helpful boost, especially for the developer who used to work with TypeScript and Angular.

  • React tends to use composition over the inheritance everywhere. This is a very good approach, and with the way the props mechanism works, it’s also very simple.

  • I realized that during the last two months of coding in React, I used JavaScript’s imperative statements like if...else maybe one or two times. Do I really need to say more?

I’ve got to the end of the beginning of my story about migrating from Angular to React. During this time, I started to really like this framework. It’s fast, clean, easy to test, expressive, and flexible. As I wrote in the beginning: I really like Angular, but surprisingly to me – I’ve enjoyed writing code in React way more. Looking these several months back, I definitely don’t regret my decision about starting coding in React. It has some small drawbacks, but overall, it’s very powerful tool that, in my opinion, thanks to its constant development and a great community, will still be the leader among fronted frameworks.

Photo of Karol Ścipniak

More posts by this author

Karol Ścipniak

Karol is a full-stack developer, who is constantly striving to broaden his programming horizons....
How to build products fast?  We've just answered the question in our Digital Acceleration Editorial  Sign up to get access

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency
Let's talk business!

Trusted by:

  • Vector-5
  • Babbel logo
  • Merc logo
  • Ikea logo
  • Volkswagen logo
  • UBS_Home