PostCSSかSCSSか。フロントエンドは時代の流れと将来性を見据えた技術選択が求められている。

スタイルシートもコンパイルするのが当たり前の時代ですが、PostCSSかSCSSどちらを使ってますか?

スタイルを書くならSCSS一択だったけれどここ1年ほどはクライアントから指定がなければPostCSSを使っていました。

PostCSSとSCSSそれぞれを趣味、業務問わず使ってみて、どちらを使うかという結論がでましました。

SCSS!キミに決めた!

PostCSSは発展途上であくまで現在できることという条件付きではあるけれど、SCSSを使おうという結論に落ち着いた。

もともとSCSSに不満があったわけはありません。

どうしてPostCSSを使っていたのか

PostCSSを使おうと思ったきっかけは、ただ興味が湧いたから。

SCSSはmixin、function、extendなどやりたいことをプログラム的に記述できる一方で、プロジェクトが進むにつれて複雑になっていました。

複雑になると使い方を忘れることもしばしば・・。

PostCSSの登場を機に1度CSSに戻してシンプルに記述してみようかと思いました。

SCSSに慣れすぎてしまった・・

PostCSSを使っていて「SCSSならこんな風にできるのにな…」って感じることが多くありました。

ネストもループも使いたい!

BEMやSUITCSSで設計するとネストできるかできないかでコードの記述量が大きく変わる。

PostCSSを使っているとネスト使えないのはとてももどかしい。

SCSSでマージンやグリッドなどで数値、定義しているカラーをループで回していたところもPostCSSだと全てべた書きになる。

めんどくさくてやってらんない!

プラグインを使えばPostCSSもネストもループできる

もちろんPostCSSでもプラグインを使うことでネストやループも使うことができます。

だけどプロジェクトを開始する度に必要なプラグインをnpm installするのめんどくさすぎるんだよね。

めんどくさいだけならまだよいものの、プラグイン使うといろんなことができすぎて、プロジェクトによってできることが違うという状態にもなる。

シンタックスが辛すぎる

PostCSS使う上で避けては通れないのがエディタのシンタックス問題。

ネストやループはそもそもPostCSSの仕様ではないから、エディタがシンタックスエラーを吐いてしまって紛らわしい・・

1人での開発ならシンタックスを全部適用して頑張ることも可能かもしれないけれど、チーム開発ではシンタックスエラーの嵐になるのが目に見えている。

もうSCSSで良くないか?

プラグインを大量にインストールしている時に「こんなにプラグイン使うならSCSSで良くね?」と思い始める。

PostCSSを使うことでメリットを感じることがあれば良いけれど、残念ながらSCSSではなくPostCSSではないといけないという点がなかった。

もうPostCSSは使わず、SCSSを使おうと決めてからなんだか解放された気がした(笑)

まとめ

フロントエンド業界に携わる限り流行をキャッチしておくのは大切。

PostCSSとSCSS問題も数年経ったら気づいたら「PostCSSを使うのが普通だよね」っていう時代もくるかもしれない。 あの時PostCSSを使っておけば良かったと思うかもしれない。

だけどフロントエンド業界なんて3年先どういう風になっているかなんてわからない。

将来的に使える仕様だからというのが理由であれば、メリットとデメリットを検討して時代の流れはキャッチしつつも今を考えて技術選択していきたい。

コウジ
Vue.jsが好きなフリーランスのフロントエンドエンジニアです。 フロントのHTML・CSS・JavaScriptの設計実装をメインに、RubyとNodeでサーバーサイドやってたりもします。
目次
    Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発