Should you migrate?
Kenshoo’s journey from ExtJS to React
This is the story of how we took a huge Javascript project, used by all our clients, avoided by all our developers, and made it great!
If you own an old legacy web application, want to start a new one, or simply love a good old adventure story with a happy ending, read on…
Before you begin: Ask why?
Before you begin re-writing your application, picking a new technology and setting to fire years of work, you must answer one simple question, why?
An engineer’s job is to solve problems and this story is no different.
In 2016, we were using a framework called ExtJS 4 which was released sometime in 2013. Back in the day, ExtJS made perfect sense, but by 2016 it felt heavy and outdated.
- With a huge footprint, our application would take about 10 seconds to load. Such performance is not acceptable for a web-based application.
- Angular 1.x was all the buzz, and finding new developers who were fluent in ExtJS and could drop into a mature project was not a simple task.
- As every complex application, the code became hard to reason with. Add that to the fact that we had no test coverage for our UI, you can imagine what it was like trying to write new features.
Obviously there were also other issues, but in this story, I’m going to focus on the three main issues:
Developers, Performance, and Experience
For us, these were the main reasons to consider migrating our application from ExtJS to a new framework.
Where to begin?
For us, the first phase was to figure out what stack to use.
In 2016, React was starting to gain massive traction and Angular 2 was already at a stable phase for exploration, so we decided to try both and find the one most suitable for us.
We took 3 developers and spent a week on each, to get a feeling of the two.
The task was to take a small screen in our application, and write a proof of concept by the end of the week.
At the end of those two weeks, we had a recommendation to adopt React.
In comparison with our experience with ExtJS, React offered solutions to our three issues:
- Developers — React was gaining traction and it was easy to find developers who were interested in working with the new library.
- Performance & Agility — React proved itself superior performance-wise in our use cases. It made it easy for us to build faster applications. React also came with the option to mix and match the best of breed tools at the time and also replace them if needed.
- Experience — As a developer, React being an open source project offered large amounts of content over the internet, from information about concepts, to issues and ideas, up to the open-source components just waiting to be consumed. For our clients we had the option to develop new modern experiences.
Baby steps…
In the beginning, React was new to us and we weren’t even close to knowing what we didn’t know yet. And of course, we weren’t even ready to replace our application any time soon.
It was now time to learn.
We found a small problematic component in our current app — the date picker — and decided that we’re going to try replacing that component with a React one.
As soon as we wrote the component and figured out how to mount and control it inside an ExtJS application, the benefits were clear.
- The component had dramatically fewer bugs.
- It had 100% test coverage for just about any scenario possible.
- It gave us a chance to learn how to use modern tools and libraries such as webpack, Babel, CSS Modules, Storybook, Redux, MomentJS among others.
Now that we had our very first component inside our ExtJS app, we felt ready to build more. Every new dialog in the application was now developed in React.
Along with a few in-house components, we enjoyed the vast world of open source React components that’s out there.
This enabled us to create our very own Kenshoo-flavored component library to re-use across projects and ensure that our users get a consistent experience, and allowed us to create a more consistent UI.
As React and other tools matured, moving in small steps allowed us to progress and mature with them, and we started contributing back in the form of releasing our own open source components to the community such as react-multi-select (discussed here).
We got better and better, learning new concepts and implementing them.
In a very backend-oriented company, UI became a very hot topic.
Along with the component and the small features, we began writing medium- sized applications that worked alongside our main application in React and were also very similar in behavior.
With each application, we refined our craftsmanship adding better in-house tools and practices.
Time to fly!
By this point, we felt that we had a great community of developers that were capable of building extraordinary things.
To keep promoting UI as a “hot” skill, we founded an internal UI guild, and invested both in UI developers across different teams, and in our UI infrastructure used by all our teams.
One of the amazing tools we released was a module that standardized our build pipeline from Jest and Webpack all the way to our Jenkins build.
This allowed us to create a Kenshoo application, with our look and feel, from scratch and take it to production within minutes.
And so, we were ready to take everything to the next level — replace our ExtJS application.
The status by then was that our core application was written in ExtJS and many smaller features within it were written in React. Additionally, similar smaller applications were created.
It was time to redesign our core application
Our new application was split into four different sections.
Grid Application is the core of this new design. It handles the integration between the different features, the server and the different applications, now called configurations.
The configurations are Javascript objects that define an application. Should the application have a datepicker? What dialogs are available? Who is the data provider for the application?
The features are designed as shared components. This means that any configuration is able to ask the Grid Application to use the feature. If an application wants the datepicker to show, it defines so in the configuration file, and the Grid Application knows to import it dynamically.
Enhancements are application-specific. These are pieces of code that are not shared between the configurations, and usually consist of the dialogs that had already been written.
This design helped us move in small incremental steps towards our core application.
We already had small applications, so they were immediately converted into configurations. The integration meant that we had to stick to a specific convention regarding how we communicate between different parts of our system which is a great thing. The Enhancements were already written and only needed to be moved.
All we had left is to add the missing features from our old application to the new application, which was a far smaller task than rewriting everything from scratch.
By working incrementally towards small features and modules, we were able to connect them all into a large, mature application that was capable of replacing our old application.
Moving to this new application allowed us to enjoy many other benefits -
- We finally had tests for the whole application.
- We could create additional applications in a matter of minutes.
- Supporting dynamic imports and code splitting with HTTP/2 dramatically reduced our loading time.
- We now had proper conventions on how to build new features because they have to integrate with the application.
If you made it all the way to here…
The world of UI is constantly changing at a very fast pace.
It’s crucial to keep up with modern standards while not over doing it by changing your technology every year.
If I could summarize my takeaways from this journey, I would suggest the following:
- Identify your issues
- Figure out what could potentially solve your problem
- Learn and then learn some more — DO NOT dive straight into solving your problem, you are most likely going to learn many things and find better solutions along the way.
Thank you for reading!
I hope you found our journey interesting and gave you some food for thought.
As always we welcome you to contribute at our small but growing open source projects.
