やっぱりSassは導入すべき! メリット・デメリットを考察したうえで、導入を薦める最大の理由

いまさらながら、Sassに関する記事です。

Sassに関する良い評判はかねてから聞いていたのですが、なかなか導入に踏み切れないでいました。
といいますのも、「導入コストに対して、実務レベルでの利点がどれほどあるのが」という点について、疑問がぬぐいきれなかったからです。

実はずっと前にちらっとお試し導入をしてみたのですが、メリットも感じる反面、細かなところでデメリットもあり、本格導入に二の足を踏んでいました。

そして…
1ヶ月ほど前に、いよいよ思い切って本格的に導入してみて、ここ一ヶ月様子を見ていました。

結果は…
やはり評判通り、Sassは素晴らしかったです。
ためらっていた自分が間違っていました。

今回は、そんなSass導入までの流れについて記事にしてみました。

Sassを導入するメリットとデメリット、ためらっていた理由、そしてなぜ導入してよかったと感じるのか等。
ただ単に「Sass絶賛」でない、一歩踏み込んだ考察をしています。

そして、Sass導入を進める最大の理由とは。

Sassについて

キーボードを叩く手

まずは、Sassについて簡単に説明します。

Sassの概要と、できること

概要

「Sass」とは、簡素に言えば「スーパーCSS」みたいな意味です。

CSSは簡単かつ明確であるがゆえに、変数や演算などの複雑な処理ができません。
そこで登場したのが「Sass」です。

従来のCSSにプログラミング的要素を加えたファイルを「.sass」または「.scss」拡張子で保存し、そのSassファイルをコンパイルしてCSSファイルを作成します。
(例えば「style.scss」のSassファイルをコンパイルし「style.css」を作成するイメージ。)

普段はSassファイルをベースにコーディングすることで、作業効率を高め、コーディングスピードを上げることができます。

セレクタのネスト(入れ子)

入れ子にすることで、コードの記述量が減り、可読性が高まります。

親セレクターの参照

親セレクターを呼び出すことができます。
:hoverや:afterなどを使用する際に、便利です。

変数

変数を定義しておくことで、後々値を変更する際のメンテナンス性が向上します。
主に、数値やカラーコードを変数にしておくと便利です。

演算

四則演算ができます。

ミックスイン

スタイルの定義が可能になります。変数の強化版のようなイメージです。
ベンダープレフィックスを記述する手間が省けるという利点もあります。

Compass

Sassのフレームワークの代表的なもの。
Sass機能を、更に拡張してくれます。

CSSスプライトが簡単に作れるのは、非常に驚かされました。

導入までの詳細が解説されている記事と本

Sassを導入するにあたり、参考にさせていただいた記事です。
非常に有用な記事ばかりですので、Sass導入を検討されている方はブクマしておきましょう。

僕はSassの参考書も買いましたが、正直なところ、これらの記事があれば参考書は必要ないかもしれません。
※より突っ込んだ学習がしたければ別ですが。

これからSassを始めたい人へ!導入手順をまとめてみた(Dreamweaver対応)
[SLab.]CSSを爆速コーディング!今すぐ始められる「Sass」&「Compass」入門!【Sass入門編】
SassとCompassを使って楽しくCSSコーディング!
Sass + Compass の基本導入と設定ファイル config.rb について

CSSをSass化するにあたり、便利なWebービス

CSSをSass(Scss)に変換してくれるサイトcss2sassが便利です。
Sass導入を検討されている方で、CSS管理しているリソース(テンプレートなど)もSass化したいと考えている方は、このサイトを使うことになると思います。

僕が利用した際は、たくさんのファイルを変換していたためか一時接続不可になったこともありましたが、時間をおけば再び利用できるようになりました。

Sassのメリット・デメリットと、それについての導入前の考え、導入後の考え

キーボードを叩く手

本題はここからです。

Sass導入のメリットとデメリットを考察しています。
導入前の考えと導入後の考えを書いているので、特に導入後の考えを参考にしてみてください。

Sassのメリット

前述の繰り返しとなりますが、Sassの機能ごとに見ていきます。

「セレクタのネスト」や「親セレクターの参照」で、記述量が減り、可動性が高まる

入れ子にすることで、コードの記述量が減り、可読性が高まります。

導入前の考え:

  1. 入れ子の書き方にやや癖があり、覚えるのに少々時間がかかりそう(閉じタグの数などで混乱しそう)。
  2. コードの記述量は減るけど、そんなに作業時間的にはそんなに変わらないだろう。
  3. CSSをSassに変換してくれるWebサービス「css2sass」では、タブサイズが「スペース2つ分」になっており、環境次第ではタブサイズのずれにより入れ子が汚くなる。
導入後の考え:

  1. 確かに、入れ子の書き方を覚えるのに少々の時間はかかります。閉じタグ不足などのミスは、はじめの頃何度も繰り返ししました。
    ただし、タブを正確に利用できれば混乱はしません。
    上記の通り、綺麗なインデントを心がければ、慣れていくうちにミスは少なくなります。
  2. 塵も積もれば山となるえす。
    やはりSass記述の方が少し早く、それが積み重なれば結構な時短になります。
  3. テキストエディタを「Sublime Text 3」にすれば、タブサイズの変更が用意なので、問題ない。
    テキストエディタ次第では、タブサイズを「スペース2つ分」に合わせなければならないかも。

変数が扱えるので、メンテナンス性が向上する

変数を定義しておくことで、後々値を変更する際のメンテナンス性が向上します。
主に、数値やカラーコードを変数にしておくと便利です。

導入前の考え:

  1. テキストエディタの「一括置換」機能を使えば、わざわざ変数を定義しなくてもいいのではないか。
導入後の考え:

  1. カラーコードであれば、確かにわざわざ変数定義しなくても、「一括置換」で変更できます。
    しかし、数値については、「一括置換」で変更しようとすると、他の変更したくなかった箇所まで変更してしまうというトラブルにあう可能性が非常に高まります。

    例えば、「$element_margin-bottom: 32px;」=「各エレメントの下のマージン」のように定義して変数を使うようにすると、このトラブルを防げます。
    これを「一括置換」で変更しようとすると、他の無関係の32pxにまで影響が出てしまいます。

    「一括置換」が使えるにしても、変数は積極的に使用したほうが絶対にいいです。

演算が使えて便利

四則演算ができます。

導入前の考え:

  1. 便利かもしれないけど、使用するだろうか。
導入後の考え:

  1. 僕は現時点では、演算機能は正直あまり使用していません。

ミックスインでスタイルの定義が可能。ベンダープレフィックスを書く手間が省ける

スタイルの定義が可能になります。変数の強化版のようなイメージです。
ベンダープレフィックスを記述する手間が省けるという利点もあります。

導入前の考え:

  1. そもそも、変数定義をするだろうか。
  2. ベンダープレフィックスもEmmetとコピペを駆使して素早く書けるため、時短になるだろうか。
導入後の考え:

  1. 個人的には、たまにミックスイン定義をするくらいです。
    ですが、気に入ったミックスインのスニペットを使いまわしたりなどもできるので、あって便利な機能であることには間違いありません。
  2. 塵も積もれば山となるです。
    いくらEmmet&コピペでベンダープレフィックスを早く書けると言っても、ミックスインでさっと書いたほうが早いです。
    もちろん、このミックスインの呼び出しも、Emmetのスニペットに登録しておくと便利です。
    例:@br→@include border-radius(50%);

CSSを圧縮することができる

Sassで管理しCSSには触らないのであれば、CSSを圧縮された形でコンパイルすることで、サイトの軽量化を図れます。

導入前の考え:

  1. 使う機会があれば良いかも。
導入後の考え:

  1. 僕はコンパイルツールとして「Koala」を利用していますが、コンパイルのスタイルは選べます。
    CSSは圧縮せず可読性を残したいという場合も多いかもしれませんが、いずれにしても設定次第でどうにでもできるので、その点は安心です。

CompassでCSSスプライトが簡単に作れる

CSSスプライトが簡単に作れます。

導入前の考え:

  1. CSSスプライトを使用する機会が、果たしてあるかどうか。
導入後の考え:

  1. 制作方針次第ですが、確かに使用しないかもしれません。
    ただ、使用しないにしても、方法を覚えるのを後回しにすればいいだけなので、特に困ることはありません。。

Sassのデメリット

導入コストがかかる

導入前の考え:

  1. 黒い画面が難しそう
  2. 上手くコンパイルされるまでの仕組みが難しく、いまいちわからない
  3. 新しいプロジェクトにとりかかる度に、Sass対応への時間的コストがかかる?
導入後の考え:

  1. 黒い画面自体は、参考サイトを見ながら真似すればいいので、実際そこまで難しくはない印象です。
  2. 学習コストは、当然掛かります。
    といっても、参考サイトを見ながらすればうまくいくはずです。
    (ただし、何らかのトラブルで意図したとおり機能しないようであれば、自ら調べて学んでいくしかありません。)

    フリーのSassやLessのコンパイラソフト「Koala」等、Sass対応をサポートしてくれるツールもあるので、実際のところそこまで難解ではないかと思います。

  3. 初期設定さえ完了し、Sassの扱い方に慣れれば、新プロジェクトにSassを導入しようと思えばすぐにできます。
    その都度コストがかかるということはありません。

クライアントサイドがSassを使えなければ、CSSで管理せざるを得なくなる

導入前の考え:

  1. クライアントがCSSを編集する可能性がある場合、こちらがSass管理であれば困る。
導入後の考え:

  1. 制作時はSassをベースに制作し、納品時に「Sassファイルを削除→以降CSS管理にスイッチ」という方法でもいいと思います。
    (あるいはもちろん、最初からCSSでもいいと思いますが。)

    Sass管理→CSS管理へのスイッチはいつでもできるので(Sassで管理していても同時進行でCSSがコンパイルされているので当然ですね)、制作段階でのみSassを利用するということも可能です。

    また、クライアント側にSassを覚えてもらうという方法もありますが、これは難しいかもしれませんね。

FirebugでCSS調査時にそのCSSセレクターの記述箇所が示されるが、Sassファイル管理なので参考にならず、該当箇所が探しにくい

なにげに、最大のネックでした。
画像付きで解説します。

Firebugの画面です。
「.post-in-single .entry-title」の項目を修正しようとしているとします。
Firebugの画面

FirebugはCSSファイルの該当箇所を示していますが、管理はSassでしているため、ズレが生じます。

「1156行目」とありますが、Sassの「1156行目」には該当箇所はありませんし、
Sassの「1156行目」には該当箇所がない

Sassファイルを「.post-in-single .entry-title」で検索しても、入れ子になっているため検索に引っかからず、該当箇所が見つかりません。
入れ子になっているため検索に引っかからず、該当箇所が見つからない

この対処法はひとつです。
最後のクラス名「.entry-title」だけで検索をかけ、見つけていくしかありません。
最後のクラス名「.entry-title」だけで検索をかけ、見つける

導入前の考え:

  1. FirebugのCSS調査における該当箇所明示の機能が意味無しになり、地味に困る。
導入後の考え:

  1. 基本的には、我慢するしかありません。
    「FireCompass for Firebug」というアドオンもあるようですが、上手く機能しませんでした。

    上記例のとおり、最後のクラス名で検索をかけて発見するしかないです。

Sassのメリット・デメリットへの考えについて、総合的なまとめ

メリットについてのまとめ

導入前の考え:

  1. 少しの時短にはなるが、圧倒的な時短になるとは思えない。
  2. 使いこなせなさそうな機能もある。
導入後の考え:

  1. 確かに圧倒的な時短にはなりませんが、塵も積もれば山となる的考え方をすると、総合的には結構な時短になっているはずです。

    特に、コピペコピペでセレクターを増やしていったりベンダープレフィックスを書いたりするのが、僕の中では当たり前になっていましたが、Sassの書き方を学べば気持ちいほど速やかにストレスなくコーディングできます。

  2. 確かに、すべての機能を使いこなせるようになるには時間がかかります。

    しかし、使わなくても問題はありません。
    まずは「セレクターのネスト」や「変数」だけでも、使ってみた方がいいです。
    特に「セレクターのネスト」の恩恵(可読性とスピードの向上)は、想像以上でした。

デメリットについてのまとめ

導入前の考え:

  1. 導入コストがかかる。
  2. クライアントがSassNGの場合、Sassを利用できない。
  3. Sassで管理すると、Firebug関連で困る。
導入後の考え:

  1. 最初だけです。
    一度初期設定を終えれば、その後は、ひとつのプロジェクトにSassを取り入れるコストは掛かりません。

    ただし、近々PCを買い換える予定があるなどの場合は、新PCに変えた後にsassを導入した方がいいかも。
    (時短の恩恵よりも導入コストが上回る可能性が無いこともないので、後回しにする。)

  2. クライアントがSassNGの条件を出しても、制作段階ではSassは使えるはずです。
    納品時以降はSassは破棄して、CSS管理に切り替えということでOKなのではないでしょうか。
  3. Sassの該当箇所が探しにくくなるだけですし、慣れれば探せます。

Sass導入をすすめる最大の理由

ノートパソコン

導入後一ヶ月位経ち、改めて評価してみると、やはりSassは便利です。

とはいうものの、個人的にはEmmet(Zen Cording)ほどの衝撃はありません。
(Emmetは「文句なしに導入」レベルだと思うので。)

メリットもあればデメリットもあるSassですが、僕が導入をすすめる理由はひとつに集約されます。
それは、「少しの時間短縮の積み重ねで、多くの時間を短縮できる」からです。
まさしく、「塵も積もれば山となる」です。

いままでよりも更に一歩進んだ時間短縮を大切にしたい方や、気持ちいいコード記述にシフトしてみたい方は、是非ともSass導入をいま一度検討してみてください。。

杉直樹
杉直樹 著者の杉直樹です。
"ライフクエスト"は、基本的にはジャンル多岐にわたる総合ブログです。
"人生をより豊かにする"と"社会をよりよいものにする"にマッチした記事をたくさん書いていけたらと思います。
お役に立てる記事があれば幸いです。

Facebookページで為になる情報をチェック

コメント