4 ms·

I think the big thing most people miss is that whilst separation-of-concerns is a great idea, trying to make the division line happen between our styles and our

by Jetrel 10y ago

I think the big thing most people miss is that whilst separation-of-concerns is a great idea, trying to make the division line happen between our styles and our logic was a really bad idea, historically. We're much better off having the "dividing lines" be between different UI components and different segments of an application. If I have some really weird custom CSS for some component on a site, I'd much rather have said CSS be embedded in the code for that one odd component - and scope-limited so it doesn't affect anything else (at my workplace we've got a common practice where any sass we write is usually scoped to only ever affect children of specific dom classes, and we use this to make sure it affects "its own kind of component, and never anything else". I've been through the hell of having totally segregated CSS, and trying to hunt down where "that one weird styling rule" is coming from is a real mess. There's also the fact that very often CSS really has to be data driven; if I'm doing a bar chart on some page and I'm using rectangular divs to represent the individual chart series, the only way I know of to set their height, client-side, is via javascript. React is quite nice because I can guarantee the presence of required dom elements for something like this, and even restructure them on the fly, and have a number of guarantees about avoiding race conditions, which I don't get via something like jQuery.

paulddraper 10y ago
It was fine when the UI was basically simple enough to be one or two components. Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation.
- flukus 10y ago
  > Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation. Maybe on the web, but we've been creating desktop (and console) applications just as complicated as any web app for a long time, that's where the importance of separation of concerns was first learned.
  - tracker1 10y ago
    Yes, but where do you separate these concerns... Do you put view rendering and raising events in separate files? From my own experience in reviewing other people's code, it depends, but usually no. I mean, you can use MVC as separation pattern, but there's also MVVM and many other patterns that place the walls in different places. I'm pretty happy with how React/Redux works compared to what came before... separating file structure by directories of features, and components/actions/reducers that represent them is much easier than looking in one spot for all my view templates with a goofy DSL abstraction, and another directory for the actual event binding.

by Jetrel 10y ago

paulddraper 10y ago

It was fine when the UI was basically simple enough to be one or two components. Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation.

flukus 10y ago
> Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation. Maybe on the web, but we've been creating desktop (and console) applications just as complicated as any web app for a long time, that's where the importance of separation of concerns was first learned.
- tracker1 10y ago
  Yes, but where do you separate these concerns... Do you put view rendering and raising events in separate files? From my own experience in reviewing other people's code, it depends, but usually no. I mean, you can use MVC as separation pattern, but there's also MVVM and many other patterns that place the walls in different places. I'm pretty happy with how React/Redux works compared to what came before... separating file structure by directories of features, and components/actions/reducers that represent them is much easier than looking in one spot for all my view templates with a goofy DSL abstraction, and another directory for the actual event binding.