Evolving Front-End User Experience: Rewriting vs Refactoring

Betfair and Paddy Power, the betting and gaming platforms part of Blip and the Flutter Entertainment Group, recently underwent a major overhaul by transitioning from AngularJS to ReactJS. This transition aims to bring together into a single experience the different products, with the main goal of delivering world-class applications that provide the safest betting and gaming experiences across the industry. 

Problem statement and rationale for maintainable codebases

The ability of our applications to meet the needs of our customers and have a well-defined, maintainable architecture is crucial for the business. Architecture and codebases begin to deteriorate over time, which causes a slowdown in the development of new features, slower applications with performance issues, security flaws, and other problems. 

Evolutionary architecture 

Being able to change and evolve our applications gradually is key for our business. We need to keep up with the industry to accommodate a constant stream of innovation in terms of tools, frameworks, and techniques because the development ecosystem is constantly changing.

Throughout this article, we will explore the journeys taken by Paddy Power and Betfair to transform our technology stacks within the customer-facing set of applications of the brands. 

As João Ferreira (Senior Front-End Developer from Paddy Power) points out:  
“There are no absolutes or a universal migration guide to follow when it comes to transition from AngularJS to ReactJS. It all depends on the way the apps are built in Angular.” 

From AngularJS to ReactJS - The need for change 

This decision was driven by the need for a more flexible and scalable front-end framework that could handle the complex requirements of the platform.  

As the AngularJS framework reached end-of-life status in 2018, our developers searched for alternatives to decommission it and were faced with a decision to be made around evolving frontend component architecture. ReactJS was ultimately chosen as the more modern and future-proof UI library to replace AngularJS as part of the technology transformation within our customer-facing applications.  

We had to decide whether to completely rewrite or refactor a codebase to make this migration when it came to the strategy for evolving the UI components. At Betfair, it was decided to move forward with a new set of features and an improved user experience for the existing products, while at Paddy Power, it was decided to use an evolutionary approach by refactoring existing components. 

Rewriting vs Refactoring

The best approach for a codebase that needs to evolve — to rewrite or to refactor — is a topic of intense debate within the industry. It all comes down to making the codebases cleaner, more maintainable, and future-proof. Which approach is best depends on the circumstances of each individual project. There are always trade-offs when it comes to software architecture, and this was no different. 

Rewriting

The transition process involved rewriting an application highly coupled to AngularJS into a framework agnostic application with ReactJS at the UI layer, ensuring seamless integration with the existing backend infrastructure. 

The upsides

• Clean slate: Rewriting gives developers a chance to start over with a new codebase, which can result in a system that is cleaner, better organised, and easier to maintain.   
• Updates to technology: Rewriting makes it possible to use the most recent frameworks, programming languages, and technologies, which can enhance performance, security, and maintainability.   
• Eliminating technical debt: A rewrite offers the chance to eliminate accumulated technical debt, creating a more reliable and stable system.   
• Better performance and user experience: Because developers can more easily add new features and address old problems, a well-done rewrite can result in better performance and user experience. 

The downsides  

• Time and cost: Rewriting typically takes longer and costs more than refactoring. It could divert resources away from other active projects because it necessitates a significant amount of development, testing, and deployment.   
• Failure probability: Rewriting carries a certain amount of risk, and there's a possibility that the new system will be less stable and functional than the original. It might also bring about new bugs and problems.   
• Inconvenience to users: Users may experience inconvenience from a rewrite, particularly if the software or service is widely used. Users might need some time to get used to the new system, and some features they were used to using might be temporarily unavailable.

Refactoring

Refactoring means restructuring code while not changing its original functionality. It entails rethinking and restructuring the codebase to conform to ReactJS's architecture and best practices. 

The upsides  

• Gradual changes: Refactoring enables developers to incrementally alter an existing codebase, enhancing the structure and maintainability over time. Since a full rebuild is not necessary, it can be done gradually and with less disruption to users.   
• Maintaining functionality: Refactoring aims to enhance existing code while maintaining its usability. Therefore, there won't be any significant interruptions to users' ability to use the software.   
• Risk reduction: Refactoring generally carries a lower risk of introducing new bugs or breaking existing functionality than rewriting because it is done in small, manageable steps.  
• Efficiency: Because refactoring builds on existing code and concentrates on targeted improvements, it can be more time and money efficient.   
• Domain knowledge retention: When working on refactoring, developers typically have a solid grasp of the current system and its domain, which aids them in making better design choices. 

The downsides

Lessons learned

• Separate business logic into components independent of frameworks: Assuring that business logic and the rendering layer are separated is key to ensuring a good separation of concerns and that those two core aspects of an application can have proper maintenance.  
• Build for evolution and change: Make things as dynamic as possible by integrating content management systems, experimentation and multi-variant testing tools.  
• Backend for Front-end pattern: Leverage Backend for Front-end (BFF) patterns and serverless for abstracting logic from the client code. 
• State management: Leverage state management libraries to abstract the UI layer from the business logic. Tools like Redux and Apollo were also added during the migration as it helped to manage state within the applications in an effective manner. 
• Design system: Leverage design system best practices for composability and adoption of design tokens is crucial. 
• Multiplatform support: We can cut down on the amount of code needed to build our applications by targeting to develop once and reuse on multiple platforms. Code reuse between native platforms can be facilitated by tools like React Native. Other tools that enable code to run on various platforms, including on the server-side, like Web Assembly, can also add great value. 

Final thoughts 

Overall, switching from AngularJS to ReactJS gives developers a more effective, adaptable, and maintainable frontend development method, improving the overall calibre and user experience of web applications.  

This transition has encouraged developers to embrace change and take advantage of the opportunities for growth and improvement. There is always a learning curve when switching from one framework to another. Everything has trade-offs, like most architectural decisions, but we should never lose sight of the goal that is to enhance the customer experience.  

With the migration, besides learning that it is important to refactor frequently and early, we have learned that sometimes rewriting small components from scratch might be more beneficial than maintaining them in the long run. We have also learned how crucial it is to align the product management, UX/UI and development teams for better decision-making and to create the best-in-class development experience for fast-paced shipping culture. 

Are you a frontend developer and this article instigated you to learn more about how we do frontend at Blip? We have the perfect opportunity for you then. Join us!