TypeScript helps a lot – you get quick traceability of where things are used and squiggly lines, if you break a contract. Yes a statically typed MVC framework would get you this, but in my experience the apps that get into this mess also don't use types "because types add too much complexity" (likely true for that company stage).
Componentization brings the other piece – self-contained components that declare their own data dependencies (load their own data), bring their own isolated styling, and generally handle all their internal behavior. This takes some skill/experience to get right and yes you can totally pull it off with every toolstack if you're good enough. The benefit is having a stack that encourages you to think about interfaces and contracts between components and hiding the messy internals from the outside world.
So for example in Flask I'm encouraging this pattern of tiny composable views: https://swizec.com/blog/a-pattern-for-composable-ui-in-flask... Once you have these, you can then move them in and out of the page with some JavaScript and an Ajax call. HTMX does this afaik and it's also how we used to build PHP+Ajax apps for a brief moment 20 years ago before client-side rendering took over for various reasons (smaller payloads mattered back then as did sharing an API between web and mobile)
edit: Point is that an approach based on composability guarantees that components won't break each other, can be moved around, and can live side-by-side without worry. The more your stack can guarantee this (as opposed to manual vigilance) the better.
Thankfully, there's a bunch of great and "easy to get going" languages now that __also__ have types (or optionally encourage them) that the "don't have types" thing isn't as much of a forced issue anymore (though engineers can still choose to go type-free and eventually face the wrath of lack of types in a large-scale project)
Yes and no!
TypeScript helps a lot – you get quick traceability of where things are used and squiggly lines, if you break a contract. Yes a statically typed MVC framework would get you this, but in my experience the apps that get into this mess also don't use types "because types add too much complexity" (likely true for that company stage).
Componentization brings the other piece – self-contained components that declare their own data dependencies (load their own data), bring their own isolated styling, and generally handle all their internal behavior. This takes some skill/experience to get right and yes you can totally pull it off with every toolstack if you're good enough. The benefit is having a stack that encourages you to think about interfaces and contracts between components and hiding the messy internals from the outside world.
So for example in Flask I'm encouraging this pattern of tiny composable views: https://swizec.com/blog/a-pattern-for-composable-ui-in-flask... Once you have these, you can then move them in and out of the page with some JavaScript and an Ajax call. HTMX does this afaik and it's also how we used to build PHP+Ajax apps for a brief moment 20 years ago before client-side rendering took over for various reasons (smaller payloads mattered back then as did sharing an API between web and mobile)
edit: Point is that an approach based on composability guarantees that components won't break each other, can be moved around, and can live side-by-side without worry. The more your stack can guarantee this (as opposed to manual vigilance) the better.