We are building several applications that will eventually be one front-end application. It is split up into several projects at the moment where each project is managed by its own scrum team.
The older applications were built on Angular 1, while the newer ones were built on React. The result is inconsistency in the look-and-feel, diversity among developers that use Angular and React, and lack of re-usable components between different frameworks (Table built in React cannot be used in Angular and vice-versa).
The decision of the higher-ups was to port React applications to Angular 1, which made a lot of React developers and even some Angular developers furious, knowing that React helps us produce better code and is easier to reason about than Angular 1. It is newer too, while Angular 1 would need a complete re-write anyway to Angular 2. However, React could be replaced by something newer in the future anyway and will be eventually old, too.
How could this situation be handled in general – where two or more javascript frameworks become dated and eventually replaced by something new while maintaining a consistent look-and-feel, and if possible, reusable components between different frameworks? Is it possible to run, as an example, Angular 1 and React on a single application?
Best Answer
There is no clear-cut answer, only a number of options:
In this case, that means sticking with angular 1 forever. It is not necessarily a bad thing. It is open source, standards-based, reliable and well documented, so essentially you can keep using it for decades even if you end up doing your own maintenance on the framework's code. The two downsides are that newer frameworks may be more productive / more powerful, and that it eventually becomes hard to attract and retain developers because you're using such dated technology.
You could for example standardize on a react table and use it from the angular codebase by wrapping it in an angular component. You can also unify the styling across the solutions. The upside is that you can integrate new technology, the downside is that you have quite a bit of overhead in ensuring everything looks the same and reuses the same components.
Retain your back-end services, but rebuild the front-end every few years on a newer technology. You allow the customer to switch to the "new layout" on login, and in the beginning it will have missing features, but what it has it may do better than the old UI. The upside is that every few years you get to start over, build it to modern standards and get rid of poorly designed features. The downside is that this rebuilding project is costly and while incomplete it means building every new feature twice (unless you can ask your users to ping-pong between legacy and new front-ends).
In all of these cases, a critical factor is that the technical choices must be made by technical people to achieve business goals set by the higher ups. A manager should not be making the call whether to standardize on angular 1 or react, just make the call that they wish to have a unified UI and set of development skills, and task the technical leads with making technical decisions that achieve that, which may include standardizing on angular 1. The decision only needs to escalate to management if the technical team does not manage to make a decision.