> some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end. If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :)
I recently greenlit a project that uses the latest Angular, C# REST APIs and a SQL server.
It's clean, it works, it's performant, it's logical and it's maintainable.
And as long as I'm still here, it's staying that way :)
(note: I agree with your approach, just making a point)
> that uses the latest Angular
But what's the migration plan for the next time Angular goes through a massive ecosystem migration and suddenly you're staring down the barrel of being massively out of date, or investing anywhere from days to months of work running just to stay in place? This is what actually seems to be the problem to me, not just in frontend either: very little is stable, and you end up piling hacks upon hacks just to try and stay up to date. People also pick new tech after being burned by previous tech doing these massive ecosystem-wide migrations and seeing how painful it is.
Speaking just for Angular, things seem to have settled down a lot. The applicaton was originally created under 13 and has been migrated to 14 and just recently to 15.
Those upgrades were quick and painless. Some new features come with each update, but aren't required to implement them and the existing code runs fine under v15.
I recently greenlit a project that uses the latest Angular, C# REST APIs and a SQL server.
It's clean, it works, it's performant, it's logical and it's maintainable.
And as long as I'm still here, it's staying that way :)