[kalkin]

I pretty much completely disagree with the implicit critique here. The codebase I work on now has largely transitioned from "semantic" CSS (classnames based on feature) to CSS with classnames that describe what they do, visually, and the latter has made writing frontend code dramatically more straightforward - it's gone from something I dread and try to pass off to a specialist to something I can do easily. A night-and-day improvement.

I mean, nobody actually advocates translating every single possible style attribute into its own CSS class. But what's wrong with padding and margin utility classes that use a consistent set of widths? Is doing calculations on "1x" and "2x" when you want elements to line up really worse than doing calculations on pixel or em values in your CSS just because it's "unsemantic"?

Let's take the examples from the "maintainable CSS" book that's linked:

  <!-- bad [sic] -->
  <div class="red pull-left">
  <div class="grid row">
  <div class="col-xs-4">

  <!-- good [sic] -->
  <div class="header">
  <div class="basket">
  <div class="product">
  <div class="searchResults">

Ask yourself, in which case can you read the code and tell roughly how it's going to render? In which case do you think you'll be able to re-use the classes on other pages? If you wanted to make another, visually consistent page that shows, say, seller search results instead of product ones, in which case do you think you'll be able to figure out which styles need to change more quickly?

Here's the backend equivalent:

  # "bad"
  def cheapest_products_with_min_rating(rating)
    products.
      select { |p| p.rating >= rating }.
      sort_by { |p| p.price }.
      first(10)
  end

  # "good"
  def products_for_category_landing_page(rating)
    allowed = []
    for p in products
      if p.rating >= rating
        allowed << p
      end
    end

    # pretend I've implemented quicksort here
  
    result = []
    for p in sorted
      break if result.length >= 10
      result << p
    end

    result
  end

Ugh, that first example - using all these "unsemantic" components like "sort" and "select"! How do I know when I look at the implementation of any of them, or the function itself, what the intent is? What business problem is being solved?

The second example - so nice and "semantic". If we want to change what products show up on the category landing page, it will be easy!

...

In real life, nobody writes backend code like that. Why should we tolerate it in the frontend?

[kowdermeister]

I'm with you. I'm not sure why semantic purists need to spread the idea that utility classes are bad. 1 class name for every property is stupid of course, but layout classes (yes, used with semantic HTML elements) are a great help if used with discipline.

After all, who are we writing code for? - The end user? He can't care less about the class names. - Search engines? They can surely identify relevant content. Semantic classes help, but they don't rule out utilities. - Ourselves? I can read utility/semantic classes well especially that I've written. Also not a case against utilities.