TECH

Vol.61

author

M.S.

Practical code design using Sass to prevent CSS bloat

#WEB#HTML#CSS#code design
Last update : 2026.4.2
Posted : 2017.4.26
In the previous article, we introduced a resilient code design approach to prevent CSS bloat, along with the implementation of Sass.
In this installment, I will walk through how to install and compile Sass using Coda 2, which I use in my daily work. Building on the previous discussion, I will also share key considerations from real-world practice, along with the improvements and insights gained.
stuffstuff

Installing Sass, using it in Coda, and Compiling

How to Install Sass in Coda

First, visit the official Coda website.

Select [ Plug-ins ] from the menu, and search for “Sass” using the search form. A Sass plug-in for Coda will appear.
Click the light green [ Install ] button to launch Coda, and Sass will be automatically installed.

If “Sass” appears under the General section in the Plug-ins tab of Coda’s Preferences, the installation is complete.

Compiling Sass (SCSS) in Coda

Create an SCSS file with the “.scss” extension, write your code according to CSS/SCSS syntax, and save the file.

In Coda, when you save an SCSS file, a CSS file with the same name is automatically generated in the same directory. Each time you overwrite and save your SCSS file, the corresponding CSS file is updated, making it convenient as there is no need to manually run compilation commands.

Key points practiced in this implementation

  • Separate SCSS files by page and consolidate them into a single CSS file using import
  • Standardize and reuse classes
  • Utilize mixins and extend
  • Avoid excessive nesting

Results of the implementation

What worked well

  • Improved readability by separating files per page, resulting in lighter and more manageable code in each file
    By dividing SCSS files by page, it became clearer which file to work on when making modifications.
  • Further splitting each page’s SCSS into two files—one for desktop and one for responsive—significantly reduced file sizes and improved work efficiency.
  • Reduced duplicate code and eliminated unnecessary descriptions
    By using shared classes, as well as mixins and extends, repetitive code was minimized, resulting in cleaner and more maintainable code.
  • Eliminated excessive indentation and overly deep selector hierarchies
    Avoiding excessive nesting in SCSS prevented the editor from being filled with indentation and reduced the use of unnecessarily deep and overly specific selectors.

What didn’t work well

 
  • Difficulty locating code due to excessive file splitting via import
    While splitting files by page improved structure, it sometimes became difficult to locate specific code. For example, after refactoring shared code, some instances remained in individual page SCSS files, making it time-consuming to find and update the intended parts.
  • Overuse of extend inheritance
    Using extend for elements like buttons led to an excessive number of shared selectors. After compilation, this resulted in a large number of grouped selectors.
    Additionally, when selectors using extend were nested and reused elsewhere, they were grouped again, causing unnecessary overrides.
 //extend)

.btn1{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{@extend .btn1; border:1px dotted #cccccc;}
.box{
.btn1{border-color:#ff0000;}
}

 //after extend compilation)

.btn1,.btn2{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{border:1px dotted #cccccc;}
.box .btn1,.box .btn2{border-color:#ff0000;}

How to improve

 
  • Write shared code in a common SCSS file from the beginning
    This may seem obvious, but layout changes are inevitable during development.
    If you find the need to refactor code into shared components later on, move it to the common SCSS file as soon as possible. If immediate relocation is difficult due to structural constraints, leave comments so the code can be easily found through search.
  • Avoid overusing the same extend declarations
    Unlike mixins, extend groups selectors into the same rule.
    While it is convenient and prevents duplication by automatically grouping selectors, excessive use can lead to a large number of selectors being chained together. To prevent this, limit the number of times extend is used, or define a single shared class instead.
  • Use placeholder selectors for controlled grouping
    Sass provides placeholder selectors specifically for use with extend.
    Placeholder selectors are defined using “%” instead of “#” or “.”. Unlike regular selectors, they behave more like mixins—they are only applied when explicitly called and are not included in the compiled output unless used.
    This approach prevents unintended grouping from other declarations and allows you to call and use only the necessary styles.
 //extend using placeholder selector)

%btn-extend{border:1px solid #000000; width:120px; font-size:14px;}

.btn1{@extend %btn-extend;}
.btn2{@extend %btn-extend; border:1px dotted #cccccc;}
.box{
.btn1{border-color:#ff0000;}
}

 //after compilation with placeholder selector)

.btn1,.btn2{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{border:1px dotted #cccccc;}
.box .btn1{border-color:#ff0000;}

Reflections on this implementation

By applying the key points and considerations outlined in the previous article, I found that the final compiled CSS was likely more optimized in size compared to before.
Since this implementation focused specifically on reducing CSS file size, and unlike refactoring, there was no direct baseline for comparison, this remains a subjective assessment. However, I believe the use of Sass and the standardization of code contributed significantly to the improvements.
That said, this exercise also revealed several areas that still require improvement, and made it clear that there is more to be done before achieving a truly efficient workflow for minimizing CSS output.
There are also Sass features that I have yet to explore and therefore could not cover in this article. Moving forward, I intend to leverage those capabilities as well, with the goal of further reducing CSS size and refining code design.

PREV
Vol.60node.jsに触れてみよう サーバーサイドJSとは
NEXT
Vol.62企画発想のコツ

MORE FOR YOU