Preventing CSS Bloat: Sustainable Code Architecture and Introducing Sass

Sass is a “meta-language” that extends the CSS language.
Based on standard CSS syntax, it adds various features that allow you to build code in a way that feels closer to programming. Depending on how it is written, Sass offers a great deal of flexibility, making it possible to significantly improve readability, maintainability, and scalability through thoughtful structuring.

There are several CSS meta-languages besides Sass, such as Less, but the “SCSS syntax” used in Sass is particularly easy to understand.
Because it follows standard CSS writing conventions, it feels more like an extension of CSS with additional functionality, allowing developers to write styles intuitively without departing far from familiar CSS syntax.

Here are some of the Sass features that are most commonly used.

// Variables
$color1 : #ffffff;

.hoge {
  color : $color1;
}

// Nesting
body {
  nav {
    ul {
      li {
        color : #ffffff;
      }
    }
  }
}

// Mixin
@mixin font($fontColor:#ffffff) {
  color : $fontColor;
}

.hoge {
  @include font;
}

// Extend
.box {
  width : 300px;
  height : 240px;
}

.hoge {
  @extend .box;
  display : inline-block;
}

For sections that share the same layout, try turning them into reusable components so that the same CSS classes and styles can be shared across multiple areas.
“Componentization” simply means treating parts of the UI as reusable building blocks.

As shown in the earlier “bad nesting example,” if styles are written in a way that only works in one specific place, you will have to rewrite the same styles again whenever you want to apply them elsewhere.
By looking at the overall site structure and turning common styles into reusable components, you can avoid duplicating the same code repeatedly.

Be Careful Not to Over-Generalize

On the other hand, overusing shared classes just because elements “look similar” can actually increase the amount of code needed for overrides and resets in areas that are not truly shared.
This becomes even more important in responsive design.
A good approach is to separate only the truly common properties into shared styles, and then use techniques such as @extend appropriately to balance reuse and separation.

The goal of preventing CSS bloat is to keep the final compiled CSS as minimal as possible. However, if the files you work on during development become bloated themselves, that defeats the purpose.
To avoid this, SCSS files should be split into separate modules and then imported into a master SCSS file.

reset.scss
animation.scss
responsive.scss

In this example, the files are separated into categories such as “reset styles,” “animations,” and “responsive styles.”
By splitting editing files into smaller parts, each file contains less code, making the structure easier to understand.
It also helps prevent issues such as slow rendering or sluggish editor performance when working with very large files.
By importing them into a master file such as style.scss, everything can ultimately be compiled into a single CSS file.

// How to import external SCSS files
// (Do not include the .scss extension)

@import 'reset', 'animation', 'responsive';

There are several different naming conventions for class names. The following three are among the most commonly used.

Camel Case　mainTitle
Snake Case　main_title
Pascal Case　MainTitle

Personally, I do not think there is a major difference between these naming conventions.
Camel case and Pascal case tend to prioritize brevity, while snake case emphasizes readability.
It is also common to choose a naming convention based on the language being used alongside CSS (such as JavaScript), or to follow the conventions that a development team is already familiar with in order to maintain consistency.

About camel case, snake case, and Pascal case
“Variable Naming Conventions” You Might Be Too Afraid to Ask About

There are several different approaches to naming conventions and CSS architecture.
Using these concepts as a foundation can help when designing CSS structure and preventing CSS bloat.
A detailed explanation is beyond the scope of this article, but here are some representative methodologies and their key concepts.

About OOCSS
Understand the Basics of OOCSS — A CSS Design Methodology You Can Apply Right Away

What did you think?
This time, we focused mainly on Sass and introduced key points for preventing CSS bloat. However, even when you understand the causes and solutions, applying them effectively in real projects is not always easy — and I am still learning through trial and error myself.
In the next article, we will begin by introducing how to install and set up Sass, which is one of the most important tools discussed in this TIPS series, so that these practices can be applied more effectively.
I hope to continue implementing these ideas one by one in order to create CSS that is both easier to read and easier to use.