> Keeping things 'DRY' and having reusable code rather than constantly repeating yourself is generally considered a good practice in software development. It en

> Keeping things 'DRY' and having reusable code rather than constantly repeating yourself is generally considered a good practice in software development. It enables fixes and changes to occur in one place, rather than having to be replicated a multitude of places throughout a codebase. It baffles me then, when CSS in JS advocates argue for essentially the "copy and paste" methodology when it comes to styling. DRY means different things in different contexts - if you are writing a utility function that is pure and has no side effects, then of course you want to write the function once. The CSS cascade, however, has a tendency to spew side effects all over your application views (e.g. one style that affects a ton of different components), which you then need to override by adding new styles. But be careful, because your new styles have side effects also! Ad infinitum.... For this reason, I regard the CSS cascade as an anti-pattern in most situations. I think that ideally, you want to isolate most of your view specific css to a module attached to the view - so that you are pretty confident that it doesn't have any side effects AND it's easy to know when you can safely delete it. That way you can avoid specificity wars and doing a paranoid but justifiable 'Search in All Files' every time you want to change a style.