|
|
|
|
|
|
by jitl
1994 days ago
|
|
|
I would rather have my files be Page.component, Header.component, Details.component, Article.component than have my three files be Page.html, Page.css, Page.js. What is the benefit of separating code by file type? If your reasoning is to reduce coupling, I think this is false simplification - again, in complex applications with lots of interaction, there is no escaping the coupling of DOM nodes, JS logic, and styles. Any feature changes change is going to need to modify all three. Maybe for a mostly read-only site de-coupling these things makes sense, and you can achieve your goals with something like Bootstrap, where you compose a bunch of reusable CSS classes. But for the majority of work I’ve done over the last 8 years, that decoupling model doesn’t work. It’s an even harder nest of snakes when you multiply 3 screen sizes x 2 input methods x N pages where CSS could be used - again for something simple, it’s fine to just collapse columns on mobile (the typical CSS column-css-6 style) but frequently you want this stuff to be much more responsive to user device and input than decoupled styles allows. |
|
|
...except that Page.css at most only adds minor tweaks that cascade over the site's styling, and arguably already should be a part of the site's main styling definitions.
> What is the benefit of separating code by file type?
Separation of concerns. This lesson was learned the hard way. Must we keep on relearning it?
> I think this is false simplification - again, in complex applications with lots of interaction, there is no escaping the coupling of DOM nodes, JS logic, and styles.
This assertion is quite wrong and misguided. Styling is a property of a site's visual identity. It is not a property of a component or a specific interaction state. Any well-designed site follows a uniform visual identity which spans over all aspects pertaining to user interactions. Moreover, UI components are also uniform and reused. There is no excuse.