Comment by dathinab
4 years ago
(Disclaimer not a web but backend dev.)
In my experience it's much more important to modularize/capsulate/segmentate by groupings of business logic then by groupings of implementation details.
Applying this to web applications (not simple text focused websites) this would mean that its preferable to have everything (HTML+JS+CSS) related to a specific widget (e.g. counter) in one place, instead of splitting it into many parts sprinkled across many files potentially in different folders. Similarly you also would e.g. want the CSS to be encapsulated as to the component as far as possible.
Its a bit of a different matter for classical html documents where the HTML made sense without JS or CSS and both where thinks you added "on top" to "just make it a bit nicer" but this isn't the think anymore for modern webapps (and many fancy websites).
Also if you work in a situation where you have many huge teams working on the same UI at the same time touching the same logical component (but normally different aspects of it) then having a more clear segregation can also make sense, but >99% of all companies are not ever in that situation.
This is also for example a major critic I have with react, it splits one logical unit across different files making it much harder to reason about it for the benefit of adding a bit more decoupling which isn't needed by >99% of dev teams.
Interesting, that makes sense. I'm thinking about a CLI analogy: you could write a program in C for the logic, some table specification markup language for the terminal layout, and a stylesheet for the colors and text styles. It would feel so cumbersome. The distinction between creating a document and a program is critical.