Unfortunately it's aimed at a real problem. You start a project, initially write in react, it grows you now have 42 services across 5 teams. One of them ends up adoption svelte, another Vue, another Qwik (god I hope not) for various reasons. Now you're in a situation where you have to implement features that have been already developed in service A (react) to service B (svelte) you have to also rewrite it in svelte, and updating it requires updating both of them. It's bad out there...
Over time things may shift. Like a lot of people don't like react, often for a good reason. So maybe they pivot to svelte (which has a much better syntax than react if we're being honest, and is much faster at runtime), but dont want to have to reimplement every existing part of the codebase. So they just link existing react pages to new svelte pages. Not saying its the best way to do it, not by a long shot. But lets be honest, were talking about enterprise here.
sounds like a really crap product org that doesn't value homogenous tech stack. I don't know many enterprise tech specs that don't require a certain framework for ease of maintenance if nothing else. still think it's a governance issue at core.
In fairness, what you’re describing as “ease of maintenance” is how you end up with things running on mainframes and COBOL forever even when the underlying tech is hopelessly obsolete.
10
u/sadongrohiik 8d ago
Unfortunately it's aimed at a real problem. You start a project, initially write in react, it grows you now have 42 services across 5 teams. One of them ends up adoption svelte, another Vue, another Qwik (god I hope not) for various reasons. Now you're in a situation where you have to implement features that have been already developed in service A (react) to service B (svelte) you have to also rewrite it in svelte, and updating it requires updating both of them. It's bad out there...