My Journey from React to Angular
This is my journey and experience of transitioning from a full-time React developer to an Angular developer.
Disclaimer: Now, this is not the story where I compare both of them, lay out the pros and cons, and ultimately choose one of them (there is enough about it out there! 😅) but it is about the journey of transitioning from one predominant UI tool (React Library) to another (Angular Framework). I am writing this because I feel this is a bit different from the norm of moving towards React, the same can be deduced from looking at Google Trends:
Prior to joining the company, I had learned React for a couple of months, created many projects in it, cleared quite a few interviews with its knowledge in some companies but ultimately got placed in a company that uses Angular!
On the very first day at of the job, we were handed down the required things to learn to get started as a Frontend Engineer. It was all in a one-page document stating the pre-requisites and things to learn. Pre-requisites involved setting up a workspace, getting Github and Zeplin access, etc. The things to learn part had Angular, Typescript, SASS/SCSS, and RxJS.
Learning
Typescript, SCSS, and RxJS
I thought Typescript, SCSS, and RxJS combined will be used in Angular so I will pick them first. Now, of all these, I had only heard about Typescript so I decided to start there. A couple of youtube videos and articles later, I felt like I knew enough about pure typescript (couldn’t have been more wrong! 😛).
In a similar fashion, I moved to learn SCSS and RxJS as well. RxJS has a lot of operators and concepts so I binged a lot of videos and practiced their content to understand it. I did the same for Typescript and SCSS as well. In about a week, I felt enough grasp on them to move on to Angular.
Angular
Thinking of picking up Angular was a bit intimidating, being a React developer, especially after I had heard a lot about it being very large compared to React and people moving away from it because of the many breaking changes they had released in the past versions (again, no judgment, just what I heard! 😭). My go-to place as you must have guessed by now is videos for learning, I tried to find the same for the Angular tutorial. I don’t know if you guys have ever googled that, but there are a lot of Angular tutorial videos out there. I trusted google on this one and picked the video which was a bit long (so that it might cover more concepts) and said Angular full course / learn Angular in ‘X’ hours / Angular tutorial for beginners etc 😎.
While learning React, I had noticed one thing — you can watch all the videos out there but it won’t make a difference until you try things out and get your hands dirty. So, I tried making some apps as explained in the videos and tried out the various concepts explained in them. There was also the official Angular docs link in the onboarding doc provided by the company. I tried it out later but couldn’t understand much from it. After all, I had only been doing web development for the past 5 months till that point and wasn’t used to learning from the official documentation.
At some point, I got the feeling that what I had tried and learned about Typescript, RxJS, and SCSS had just scratched the surface, and implementing the app using Angular and these tools in it was an entirely different experience than trying them out individually. After a week of doing all of the above again and again and googling everything else about Angular that I didn’t understand, I felt confident (and honestly very saturated) enough to go to the Frontend Lead and ask for working on the project.
Getting Started
Estimating time frame
I would have hoped that at this point I had learned enough about Angular to handle my own while coding in a production environment (again, couldn’t be more wrong!). The lead engineer explained the task and it sounded a bit long, intimidating, and complex (In retrospect, I was a beginner so anything would have 🤔). Then he asked for an approximate time frame for me to complete this and after some hesitation, I said 3–4 weeks!! He laughed and said, “I was expecting more like a week” and so I also laughed at my time judgment skills and asked for two weeks since I was new to coding in a company as well as new to the framework.
Coding
Now came the Herculean task of working on this project. I will be honest, it took me a very long time (longer than I am proud of) to even find the correct file and line to start writing my code 😆. Thankfully the Lead had explained to me how to use Zeplin to get the designs (paddings, margins, colors) and also a brief tutorial of good practices about coding in Typescript like defining types of all structures you will use, adding interfaces and enums to access Typescript’s amazing IntelliSense, etc. That saved me a lot of time and mistakes.
Learning from existing code
At this point, I had just heard about services, custom directives, modules, etc and I ended up spending a lot of time looking at already present code to get an idea of how to manage, structure, and implement my work. How to use existing services to make API calls and existing directives to avoid duplication of code. That first task took a lot out of me. There were constant design and implementation changes and I had to shift my approach accordingly. At one point, I realized that I had written so much redundant code that it took me half a day to refactor it and it ended up being half in size!
Getting Comfortable
It took a couple of more tasks and about two months of time to get comfortable enough to be able to find my way around the giant codebase and be able to give pretty close time approximations on the tasks. After over 9 months (present time), I still won’t say that I have mastered the framework. Actually, I am pretty sure that there is a lot more to learn than I have so far.
What I Learned
All that said, this experience made me realize that as long as you’ve got the basics, the choice of the framework shouldn’t matter. Of course, there will be a point where you have to choose one and it will come with a learning curve but one should not hesitate in picking up one or the other tool to get the work done because at the end of the day, these are just tools and those can change anytime.
There is no saying what tool will come in the future and how much more efficient and useful that could be. We should not develop a bias for one tool over another. Any decision to be made can be done so by actually analyzing the metrics around them, trying them out, and logically weighing what they have to offer. I am mentioning this because I have seen a lot of people showing bias for one framework/library over the other without being able to justify their choice and that is a Red flag in any interview or company.
I believe — It is the engineer that makes a tool great and not the other way around.
After this experience, I am confident that I will not be hesitant in picking up any tool like React, Vue, etc in the future.
