The initial part of the site is really bad advice. Dismissing utility classes upfront due to lack of knowing meaning is naive; every code base has a learning curve and making developers write a grid class for each component is not maintainable due to its time cost.

In my experience, a module/component heavy system with opt-in utility overrides has been the most practical and maintainable. For example:

• Grid system as classes
• Components as their own set of classes (e.g. tabs, modals)
• Utilities as one-off overrides (e.g. margin-left by 1 spacing unit)

Some things I do agree with:

• Components are a good idea
• An excess of utility classes is frustrating to maintain because there’s so damn many

Some flaws I see in the examples provided by the site:

• Anything where you directly reference a color or content is going to blow up in your face unless it’s custom to a custom site style
  • This prevents reuse across multiple sites (which should be the goal for most companies as designers want to reuse components in designs to save time too)
  • Instead, it’s best to use schemes like “primary”, “success”, “error”, “dark”, “light”, etc. These will tolerate maintenance changes down the line

For those curious, I use typically Inuit.css@5.0.1 (6.0.0 exploded itself into little packages which it looks like it’s started to undo) with BEM and OOCSS mindsets:

• https://github.com/csswizardry/inuit.css
• https://en.bem.info/methodology/naming-convention/
• http://oocss.org/