The Journey from Angular 2 to React

Chances are, if you’re a JavaScript developer and you find yourself at a new job, you likely won’t be using the same frameworks or libraries you used at your previous place of employment. Even if you’ve decided that a certain framework is going to be your one and only, the JavaScript ecosystem is too diverse and moves too quickly for that to be a realistic career goal.

When I started my current position at Seller Labs I was completely new to React. Before that, I was working on an application using Angular 2. Back when I learned jQuery, I had a huge lightbulb moment when I remembered jQuery was still, at its core, JavaScript. I could still do all the things I’d done before in plain JavaScript within my jQuery.

I took myself back to that memory when I started learning React. Feeling overwhelmed with new information, I took a deep breath and reminded myself it’s still JavaScript. It’s the same language you’ve been programming in for years, just used in a different way. But I’d gotten so used to doing things The Angular Way, it was hard to make such a sharp turn. This is not an article about the differences between the two; there are already plenty on that topic. Instead, here are a few of the roadblocks I ran into on my journey from Angular 2 to React.

TypeScript, I Hardly Knew Ya

When developing my Angular 2 application, I was working with a bunch of C# developers who loved static typing. This was one of the reasons we picked Angular 2 to begin with; it’s structure is familiar to those who have been developing in .NET MVC for a long time. But I was a JavaScript developer. I thought dynamic typing was a feature.

Angular 2 uses TypeScript by default. While it’s possible to use Angular 2 in pure JavaScript, most of the documentation is written for TypeScript users, and TypeScript users get access to a wider array of features. That, paired with my coworkers’ fondness for static typing, made going with TypeScript the best option. It was hard. At first, my code was riddled with errors I didn’t understand. But after practice and with the help of Google, using it became a habit.

While it was difficult to get used to, I must admit that my time using TypeScript helped me write better code. Once I got the hang of it, and it helped me think through my code before I started writing it. This helped me catch my errors earlier in development, and I found working with others’ code easier because statically typed code is more clear. Here’s an article on the benefits (and some drawbacks) of static typed languages if you want to learn more.

Of course, React doesn’t require TypeScript. It’s possible, but most React developers don’t choose to use it. Most documentation, examples, and other resources are not in TypeScript. I’ve found myself enjoying the benefits of using a dynamically typed language again. While I don’t particularly miss TypeScript, I hope to continue the same level of consideration when writing my code that I learned when using the static typing superset. Also, React’s PropTypes encourage typing of the extra important stuff: Props that are passed to and from components.

The Many Roads of React

I was okay leaving TypeScript behind, but I was less pleased to find out that React did not have a React CLI like the Angular CLI. The Angular CLI is a time-saving tool that allows you to quickly create Angular 2 components, modules, directives, etc. with one little command. Run the command and Angular 2 would do all the dirty work of setting up the necessary imports and exports for you. You’d have a working component ready for you to build on.

React doesn’t have this. It’s much less prescriptive about how you build your application than Angular 2. This has many benefits, like being able to tailor it specifically to the application you’re building. It’s less great when learning how to use the library. Angular 2 was new when I used it, so there weren’t many community resources like blog posts or Stack Overflow questions and answers. However, the stuff that did exist was all very understandable because everyone used Angular 2 the same way. Everyone Reacts differently. I even found this within our own codebase where old best practices still existed in some code while newer, better ones were used elsewhere.

JSX

When I started learning JavaScript I started with little snippets added to HTML page to provide the appearance of something dynamic. It wasn’t long before separation of concerns became best practice: HTML, CSS, and JS are all in separate files and shall never meet. Ever. Angular 2 used HTML templates that contained bits and pieces of JavaScript. React scraps the whole separation thing altogether.

This was probably the hardest thing for me to wrap my head around, and I still struggle. Not because I don’t understand it, but because I’ve been writing CSS for so long it’s muscle memory, and remembering to write fontSize instead of font-size and put my properties in quotes was hard. It was like someone told me I suddenly had to start speaking a new dialect of English.

I understand that in React we’re dividing up our code in a whole new way. Instead of separating layout (HTML), presentation (CSS), and behavior (JavaScript), but instead separating by components–independent reusable chunks. The new paradigm makes sense, but it’s hard to undo so many years of thinking.

React is Easier to Learn

Despite the lack of prescriptive code structuring and weirdness of using JSX, I still had an easier time getting the hang of React than I did Angular 2. I think that’s because the whole concept of React is simpler than Angular 2. React also has a much stronger community: there are blog posts, videos, training material, and a plethora of Stack Overflow examples all over the Internet.

Being that React doesn’t require TypeScript, it feels more like writing vanilla ES6 than something trying to be C#. I can remind myself that it’s “just JavaScript” and be on my way.

Conclusion

After developing in React for over two years now, I’ve come to appreciate some of the parts that I found difficult when initially learning. Even though I still try to write “normal” CSS sometimes, it’s nice not having to create a separate file just to hold a few styles. Not forcing engineers to build their applications in a specific way means we can be more flexible with our approach and create more robust products. Changing best practices means we can continue to evolve and improve our code.

But I still miss the Angular CLI.

Leave a Reply