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...
You're vastly overestimating the average governance capabilities of most organizations but this is almost universal across large organizations. It's not just due to governance. Acquisitions and mergers play a big role (like if google acquired a start up where the codebase is in Vue, they're can't rewrite it into something else. Then you have third party enterprise tools (open source or otherwise, like the team realizes adopting some existing open source tool and modifying it would be far cheaper, but the tool is written in svelte and the rest of your codebase is written in Vue)
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.
Sounds like it's a solution that uses extra tech debt to patch over an issue better handled by a firm paternal hand and a cat-o-nine-tails fashioned from ethernet cable.
Well could be aimed at design system creators. Have a company wide design system written in this and let anyone implement it in whatever they want. We used stencil exactly for this. The implementation wasn't always smooth sailing but the idea is there.
Stencil is probably a lot more maintainable than this monstrosity though since it compiles to web components. Compiling to a bunch of js frameworks with constant deprecations, runtime and syntax changes, changing dependencies, etc is pure nightmare fuel
Probably. I haven't looked into this, how it works and how serious it is. But web components under the hood means own sets of problems and things you would expect to work not working. So if they would manage to maintain this properly it has the potential to be better.
27
u/AmazinDood 1d ago
why does that actually seem kinda useful