Why are we migrating from AngularJS to React?

Published in

Click Travel Engineering

4 min readJun 1, 2021

At Click Travel we’ve chosen React as our frontend tool of choice, so we thought we’d share how we got to that decision and some of the reasons behind it.

Goodbye AngularJS

At Click the majority of our customer-facing apps are built-in AngularJS, which entered Long Term Support in 2018; only security and compatibility issues will continue to be fixed until December 31st 2021. As a company, we need to be able to keep up with the security expectations of our customers and to sustainably add new features, which would become more difficult with the end of long term support.

This introduced a dilemma for us. We knew that newer flavours of Angular were different enough that they would require a significant rewrite, so we decided it was time to see what was on the market.

We began by testing Elm as a replacement for AngularJS. Starting with internal apps, to gain enough experience and build a solid base to move on to external apps.

Maybe Elm?

The Elm experiment was quite successful, it gave us many of the things we were missing in AngularJS such as no runtime exceptions, strong typing and enforced semantic versioning.

This came with some cost though, some developers found Elm quite difficult to pick up due to the unfamiliar syntax and the smaller pool of online support that comes with a less popular language.

On reviewing our experiences with Elm, we realised the main blocker for adoption was its ownership model, it’s a closed source language managed by a single founder. So at the same time, we decided to investigate React.

Why React?

We had previously built a large internal app using React, which was still in service. But that was created some years ago, so we took another look at how the React ecosystem and best practices had developed since then.

If you didn’t know, React is developed and used by Facebook, reassuring us it’s not going anywhere anytime soon. Its huge community and ecosystem mean documentation is abundant and most issues are likely to have already been solved or at least mentioned on StackOverflow. Much of the tooling we are used to in our Node.js microservices can also be used in React, which will help to shorten the learning curve.

With the advent of hooks, we can say goodbye to class components, lifecycle methods and all the complexity that comes with them and replace them with functional components and hooks, which fits in nicely with our preferred functional programming paradigm.

“Hooks are functions that let you “hook into” React state and lifecycle features from function components.” — source

But the real awesomeness starts with custom hooks, which allow you to share and modularise stateful logic between components, like Lego bricks.

Redux even took this approach and wrapped its codebase behind some custom hooks. The result is that you can use all that Redux can offer in terms of robustness and safety by writing minimal and super simple code — with hooks.

As part of our technical review process, we took all this into account and looked at many other factors too, such as the learning curve, maintainability and scalability — and in the end, we felt that React met these requirements the best.

React isn’t the final replacement

All that said, we knew React wasn’t a complete solution. Where AngularJS had given us a full framework from state management to routing, React gave us a much more slimmed down library with a huge ecosystem of options to “tack-on”.

Our first task was to investigate the missing parts we needed and establish the best practices to share with other crews at Click. So we did a deep dive into some of the tools we would need early on, from linting and type systems to testing frameworks and state management.

Then we needed to investigate how we could start migrating two very different technologies in a lean ship-early-ship-often approach, which we’ll go into in our next blog… spoiler alert it includes federated figs…