Thanks for adding this comment. Having good CSS practices is important, but if a module has styles that only it should ever see, why the abstraction to another file/location is beneficial is puzzling me. Bulkier CSS or bulkier templates? (And if those templates are rendered programmatically on the client like many single page applications there's no penalty due to js caching.)

I guess you don’t have to maintain those projects. You’re coupling the style to the view so tightly that any updates in the future will be serious effort.

As a counter-point, the "style" is usually heavily coupled to the "view". It's rare to see a re-style which wouldn't also require a reworking of the view anyway.

I like the idea of purist separation of "style" and "view" but it's unrealistic to think it needs to be a point of dogma.

There are clearly cases where you would want most your styling to be separate, particular for client-specific branding, but there is likely "functional" css such as css that gets date pickers etc working and those can't really be cleanly separated from the view.

A lot of CSS isn't really "style", it's actually far more functional than that. Try turning off CSS and see what happens to fancy date-pickers or rich text editors or other controls, they don't degrade cleanly they just break.

I’m not talking about a complete rebrand, but let’s say your a/b testing discovers that users react better when there’s 20% more whitespace between elements. If you’ve got all your margins contained in your CSS (or better yet a global SASS variable to control default gutter sizes) then it‘s trivial to update and push. If you have to search through every view in your project to see where you might have snuck in some inline styles… well, you’re just not going to bother. Which means you’re throwing user need / conversion away.

In the react style he was talking about, you would import reusable styles so you can still change just one variable to update the gutter size.

Can you elaborate? The design is modular. Reusability of styles is implicit in the re-use of components, it's not like you duplicate styles all over the place (or at all). In my experience maintenance changes have been easier, since it's a piece of cake to nail down exactly what component the styles belong to by quickly scanning the code, eliminating the need to inspect the DOM to discover which selectors are impacting a certain element.

You can get the same functionality by structuring your SASS into a components/* tree that maps to your components. That way your styles can use global style variables that are shared throughout your project, which in turn reduces the maintenance load.

(to be fair, React doesn’t seem to solve more problems for me than it creates - quite the opposite - so I’ve never built anything past toy apps in it)

> can use global style variables that are shared throughout your project,

... which you can just as easily do in React. It's JS after all, so you just use JS modules -- and I hasten to add that there are probably-better-than-plain-JS solutions out there[1].

[1] Here's one example: https://github.com/gajus/react-css-modules . (Dislaimer: haven't actually used this, I'm using scala.js)

Wait, the style and view typically are coupled.

There needs to be a happy medium. Projects that go to extremes to decouple everything are

a) a waste of much effort for little gain. b) as big a pain to work with as code that is completely coupled.

Yes, I think one way coupling isn't really a problem - your controller knows about your model layer, but not the other way around.

IMO react is a special case...

I think what that line is trying to convey is that you shouldn't be doing things like adding a script tag that goes in and sets all classes to have "background-color: red", and to try to avoid using JS for animations/transitions where possible.

Just like when someone says don't HTML and JS, they aren't talking about JSX most of the time.