Why CSS Grid Layout doesn't replace the framework's grid

I've come across many articles and comments stating it's time to replace the framework's grid system with CSS Grid Layout. I can't entirely agree.

⚡️ Design 10x faster with our library of 326 components →

Framework Grid vs CSS Grid

A framework's grid is a "package" of utility classes that can be used in any project to distribute elements in (responsive) columns and rows. It could include hundreds of lines of code or just a few rules. It could be that-framework-name's grid or your custom grid system.

Here's an example from CodyFrame's grid system:

<ul class="grid gap-md">
  <li class="col-12 col-6@md"><!-- ... --></li>
  <li class="col-12 col-6@md"><!-- ... --></li>
  <li class="col-12"><!-- ... --></li>
</ul>

CSS Grid Layout is a subset of CSS properties used to distribute elements in (responsive) columns and rows.

For example:

.component-name {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
}

Any framework is an abstraction that uses CSS; it doesn't replace it. Consequently, we can't compare a framework's grid system with CSS Grid. The former could use the latter (i.e., a framework's grid system based on CSS Grid). The question "Which one is better?" doesn't make sense in this case.

However, we can discuss whether it makes sense to include a package of utility classes now that we have such powerful CSS layout properties.

Short answer: it may not if you're working on a small project. It does make sense the moment your project grows in complexity.

Enough with the theory! Let me show you an example. 👇

Starting a project using only CSS Grid

Let's imagine we're starting a project where, at some point, we need to create a grid.

.gallery {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

As we move forward with the project, chances are we need to create more grids:

.gallery, .form-grid, .list {
  display: grid;
}

.gallery {
  grid-template-columns: repeat(2, 1fr);
}

@media (min-width: 48rem) {
  .gallery {
    grid-template-columns: repeat(4, 1fr);
  }
}

.form-grid {
  grid-template-columns: minmax(100px, 250px) 1fr 1fr;
  grid-gap: 20px;
}

.list {
  grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
}

So far, so good! If our project was mostly done, why bother even thinking about importing a grid system? CSS Grid easily gets the job done.

The project grows in complexity

Imagine we need to apply the same grid to two components. What are we supposed to do?

Option 1) Use the same class.

<div class="form-grid">
  <!-- ... -->
</div>

<div class="form-grid">
  <!-- ... -->
</div>

<style>
  .form-grid {
    display: grid;
    grid-template-columns: minmax(100px, 250px) 1fr 1fr;
    grid-gap: 20px;
  }

  /* we decide to use the same class 👆 */
  /* .portfolio-gallery {
    display: grid;
    grid-template-columns: minmax(100px, 250px) 1fr 1fr;
    grid-gap: 20px;
  } */
</style>

This approach could go wrong for many reasons. First, a picky developer who loves semantics would dye inside a little. Most importantly, we would create an invisible connection between two components: changing the CSS of the first one would affect the second one. You're creating a trap for your future self.

Option 2) Create a new grid.

<div class="form-grid">
  <!-- ... -->
</div>

<div class="portfolio-gallery">
  <!-- ... -->
</div>

<style>
  .form-grid, .portfolio-gallery {
    display: grid;
    grid-template-columns: minmax(100px, 250px) 1fr 1fr;
    grid-gap: 20px;
  }
</style>

Creating a new grid for the new component and grouping the classes would be the safest approach. Besides, it won't affect the CSS size.

Now imagine we get to the point where our project needs multiple (similar) grids. Should we keep creating a new grid for each component?

.gallery, .form-grid, .portfolio-gallery, .contact-gallery, .list {
  display: grid;
}

.gallery, .form-grid, .portfolio-gallery {
  gap: 20px;
}

.form-grid, .portfolio-gallery {
  grid-template-columns: repeat(3, 1fr);
}

.gallery {
  grid-template-columns: repeat(2, 1fr);
}

@media (min-width: 48rem) {
  .gallery {
    grid-template-columns: repeat(4, 1fr);
  }
}

.contact-gallery {
  gap: 16px;
  grid-template-columns: repeat(4, 1fr);
}

.list {
  gap: 40px;
  grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
}

Here are the weakest points of the above approach:

1. Even though the grid classes are in the same SCSS file (highly unusual - typically, they'll end up in different SCSS/component files), and the number of grids is relatively small, dealing with the grid system is already getting more complicated.
2. Each grid requires a different class name, and naming too many things can be frustrating.
3. Because the classes are intertwined, modifying, or creating new grids requires a high concentration level. The risk of breaking things is high.

Sooner or later, we end up doing that only thing that makes sense: we create abstractions.

.grid { display: grid; }
.grid-col-2 { grid-template-columns: repeat(2, 1fr); }
.grid-col-3 { grid-template-columns: repeat(3, 1fr); }
.grid-col-4 { grid-template-columns: repeat(4, 1fr); }
.grid-auto { grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); }
.gap-sm { gap: 16px; }
.gap-md { gap: 20px; }
.gap-lg { gap: 40px; }

Our grid utility classes are born out of necessity!

Here are the main advantages of abstracting grid utility classes:

1. All the grid utility classes are in the same SCSS file and are easy to read.
2. You can quickly expand the system if required by the project.
3. No more naming things.
4. If you use the same grid system across multiple projects, you won't need to inspect the CSS at all.
5. Dealing with simpler CSS means reducing the risk of breaking things.

Conclusion

The main goal when working with CSS is maintainability: do what makes your code easier to maintain.

When working with grids, that means using utility classes if the project becomes more complex. It also implies creating the grids in HTML rather than in CSS. The "separation of concerns" is not the topic of this article. If you're interested, here's a video where I explain how we use utility classes at CodyHouse.

"Are you suggesting we should import a package of hundreds of CSS lines in every project just to manage the grid system?" No.

The framework's grid systems are usually massive because they include all the options, some of which you'll never use: responsive modifiers for all the breakpoints, offset, gap options, and so on. However, modern tools like PurgeCSS prevent your CSS from bloating and include in your CSS only the classes you actually use.

Are you looking for a great grid system? Check out CodyFrame. 

Feedbacks/suggestions? Get in touch on Twitter. We'd love to hear what you think.