alt Hacker News> Do we need to keep all the layers in mind, or not?
With MVC/MVVM? Yes, but not all at once. That is, you focus on one layer at a time. You think about its inputs and outputs, and how it interacts with other layers. Then you follow the data to the next layer, and so on.
With JSX, or any project that disregards SoC, you're forced to think about all layers at once. You have to think about how the JS processes the data, and at the same time how this impacts the content and final rendering.
It would be like if on the backend you would mix business logic and data processing layers, or more accurately, put business logic AND your views inside your database. There are developers who don't mind or even argue for this approach, but most developers would agree that this is an insane way to build applications. Yet on the frontend, for some reason, everyone is fine with this.
To give a concrete example, take a look at this page from the React docs[1]. Ask yourself this: what is the structure of the page at any point in time? Is any component modifying data? What happens if it does? What happens if a component renders a structure that is incompatible with other components?
This is a trivial example, so some of the answers are evident, but in a real-world application these and many other questions are very difficult to answer. Especially by staring at the code during a review. I've found that the only reliable way to review code in a modern frontend framework is to run it locally, see what the behavior and rendering is, and correlate that with the changes. And, of course, since there is usually a complete disregard for UI and E2E testing of any kind, this process is error-prone and regressions are common.
> It’s a trade off between separation-of-concerns and locality-of-behavior.
These are often seen as opposing principles, but it's possible to have both. A single HTML file can contain HTML, JS and CSS. Each section has a single concern, but would you argue that LoB isn't preserved?
> any abstraction has a cost of increased cognitive load
None of these principles or models are abstractions. They're design patterns that suggest a certain way of thinking about and organizing an application that makes reasoning about it and maintenance easier.
> If I have to look at 5 files instead of 1, the 5 files better pay for itself in some way
Again, SoC is not about putting things in different files. It's about a logical separation between different parts of the codebase. Whether that happens in a single file or multiple is up to the team to decide.