I liked the article, but there&#x27;s something I need to point out regarding CSS preprocessors. It&#x27;s way more important than making CSS &quot;a bit better&quot;.<p>Preprocessors allow you to achieve modularity and DRYness. They allow you to move the object-composition duty from the browser to the build process - hence avoiding overloading the browser with composition (i.e. composing a class with SASS mixins or extends, instead of plugging many classes in a single HTML element). They allow you to easily express relationship through class names instead of relying on DOM hierarchy (separation of concerns). And, obviously, they allow variables! Common and centralized palettes, sizing definitions, typography definitions; also, &quot;computable&quot; definitions (e.g. deriving a shades&#x2F;tints palettes via the built-in color management functions, or computing a typography scale from a base size).<p>If you have the time to learn CSS and a preprocessor adequately (and think about how to tackle common architectural issues having these characteristics in mind, isntead of borrowing solutions from e.g. OOP), then you might have clean, elegant and maintainable CSS (instead of a hairy jungle of rules that nobody in your team would want to mess with).