MV(C/VM/P) is in fact one of the front-end alternatives to components.
> You don't need MVC to compose large UIs in web apps.
As the argument was that components were the obviously correct solution to that, I think the poster you are responding to would agree you do t need MVC, etc., for that, but they are still used for it.
> You use the MVC pattern to separate concerns: fetching data from the database (M), presenting said data (V), handling requests and managing sessions (C) and because the pieces of code live in different places: MC on the server, V in the browser.
Classical MVC was for local GUI apps, an the later original web MVC had all three components on the backend. (View being the conponent that rendered final HTML, or XML/JSON for APIs, often from templates + objects from the controller.) In web frontend, the M usually interacts with APIs rather than DBs, the V still renders HTML, and the C, VM, or P does it's usually role.
> The whole "top-down..bottom-up" thing is a mechanism that only makes sense when you have decided that you want to have some sort of SPA,
Sure.
> it isn't something you _need_
I'm not sure what want/need distinction you are trying to make here.
> or an alternative to how things were done before
Both having a SPA and using components vs other approaches for a SPA are alternatives to what was done before. You seem really only to be disagreeing with the latter, but HTML+JS apps that were SPAs (even if the name wasn't originally in use) are almost as old as JS, and much older than component based approaches.
You are right in correcting me that MVC et al. can also reference something other than frameworks like Rails. I may have jumped the gun there.
> I'm not sure what want/need distinction you are trying to make here.
What I feel is happening in these discussions is that people take the issues they run into when creating SPA with component frameworks (state management, making calls to back ends and error handling to name a few) and present them as fundamental issues of creating web applications.
When React first came out, you quickly ran into the issue that, for a bigger application, you needed to pass too many parameters through the whole stack to reach the outermost components just to update something like a counter badge, etc. Then came Redux and it 'solved' this.
This issue of passing parameters down the component stack is only an issue within the context of using a stack of components. It isn't one of the issues that exist when building a web application using server side rendering. So what I mean with 'you don't need' state management in the front-end is that the issue of managing state is completely inherent to building a UI with components, it isn't an absolute problem of creating web applications.
MV(C/VM/P) is in fact one of the front-end alternatives to components.
> You don't need MVC to compose large UIs in web apps.
As the argument was that components were the obviously correct solution to that, I think the poster you are responding to would agree you do t need MVC, etc., for that, but they are still used for it.
> You use the MVC pattern to separate concerns: fetching data from the database (M), presenting said data (V), handling requests and managing sessions (C) and because the pieces of code live in different places: MC on the server, V in the browser.
Classical MVC was for local GUI apps, an the later original web MVC had all three components on the backend. (View being the conponent that rendered final HTML, or XML/JSON for APIs, often from templates + objects from the controller.) In web frontend, the M usually interacts with APIs rather than DBs, the V still renders HTML, and the C, VM, or P does it's usually role.
> The whole "top-down..bottom-up" thing is a mechanism that only makes sense when you have decided that you want to have some sort of SPA,
Sure.
> it isn't something you _need_
I'm not sure what want/need distinction you are trying to make here.
> or an alternative to how things were done before
Both having a SPA and using components vs other approaches for a SPA are alternatives to what was done before. You seem really only to be disagreeing with the latter, but HTML+JS apps that were SPAs (even if the name wasn't originally in use) are almost as old as JS, and much older than component based approaches.