> 1) clutters the HTML, Or, it makes your HTML far more representative of the state of your application, rather than having to open up a CSS file and match to

> 1) clutters the HTML, Or, it makes your HTML far more representative of the state of your application, rather than having to open up a CSS file and match to the class name + whatever madness you have going on in your SASS with mixins and conditional style logic. > 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that) Blindly following DRY is dogma. Not everything can (or should) be a component. The number one mistake I see with new React developers is "over componentization", where everything is a sub component, and now I'm digging through 5 different files to work on a feature. Use the "rule of three" here. The first time you write something, don't even think about making it a component. The second time you write it, start planning how to generalize. The third time you need it, make it a component. Copy/pasting is OK. Declaratively laying out your UI rather than generating it through configuration is OK. Having no abstractions is better than a bad or even mediocre abstraction.