CSS フレームワークが辛い。
ここでいう CSS フレームワークとは Bootstrap とか Bulma とかそういうやつのことである。昔から自分はこういうのが苦手で、一定の便利さは感じつつもどうしても馴染めないという状態が続いていて、それでも「それは使い方が悪いだけで、ちゃんと使いこなせばペイするんだろう」と思って今までズルズル使ってきてしまったのだが、やっぱりそれでもどうしても辛くなり脱フレームワークしようと思う。
もちろん使いこなせる人には使いこなせるんだろうし「使うべきでない！」という主張をするつもりはない。頭のいい人には使えるんだろう。昔は「今すぐ〜すべき 10 の理由」みたいなことを適当に書いてたんだけど、どうせ自分がやってることは「 Web 系」のメインストリームからは外れてるんだろうし、合わせるつもりもなければ合わせさせるつもりでもない。使う理由も使わない理由も人それぞれだけど、少なくとも自分には無理でしたというだけの話。
前置きが長くなった。以下、個人的に CSS フレームワークをもう使いたくないなと思った理由。
CSS を書く方が楽
そもそもこれ。 CSS はモジュール化しにくいなどの欠点はあれど、生で書いてもそれなりに使いやすい。だからフレームワークで間に合わなかったり気に入らないスタイルがあるとすぐに CSS を書きたくなってしまう。しかし独自にスタイルを書いていくとフレームワークの世界観を壊してしまうので、なるべくフレームワークの文法とシステムを使って書こうと思うわけだが、これが全然思うように行かなくて歯がゆい。「ここを目的のスタイルにするためには、あのクラスとこのクラスを組み合わせて...」というのがとにかく難しくて「こんなの CSS 書けば一瞬で解決するじゃないか」という気持ちと戦いつつ、頑張ってフレームワークの文法を使って書いてみるも、結局思った通りにいかず最終的にぎこちなさの残ったスタイルになってしまう。
学習コストが高い
フレームワークを使うんだから楽がしたいのだが、学習コストがとにかく高い。もちろん上手くレスポンシブをやってくれたり、その辺はその道の達人が作ってるはずだから、払ったコストに対してペイするものだと思ってやっている。が、それでも難しい。なんどもなんども忘れて公式サイトを確認しにいくがそれでも忘れてしまう。 CSS もなんども調べなおすんだけど、こっちは Web 標準だからまだ良くて、フレームワークは本当にその場限りの知識になってしまうからガッツリ時間をかけて学習する気にもならない。
サンプルからルールが読み取れない
「こう言う感じのヘッダが作りたかったらこういう風に書くんだよ」というサンプルコードと絵が対になって紹介されているドキュメントが良くある。サンプルそのままの見た目でいいならそれをそのままコピペでいいんだけど、細かいところがちょっと予定と違っていたりして、その部分だけを変えようとすると途端にわからない。要は、 ABCDEFG という７種類のクラスが 30 行くらいの中にわっと書いてあって、そこからどういうルールでスタイルが適用されているのかを推測するゲームになる。
運が良ければ要素ごとに分解して書いてあるけど、それでも「こんな感じ」とサンプルがどーんと乗っかっていてかなり曖昧。わからないから「このクラスとこのクラスをネストさせるとこういう風になるんだろうな」と適当に想像したり、もっと知りたいときは「検証」で開発者ツールを開いて調べるんだけど、サンプル用に特別に当てられたスタイルとかもあって、自分のアプリ上に持っていくとその通りのスタイルにならなかったりする。で、開発中のアプリとドキュメントを行ったり来たりして「ここを変えたらここが変わったからつまり...」と何度かあれこれ試しながら見た目を整える作業がひたすら辛い。で、完成しても結局ルールはわからないまま。
意図のわからないルール
ルールを理解しようと思ったらコードを読めばいいんだが、 .foo > .bar:not(.is-hoge) .fuga みたいなセレクタを見て「あーそうですか」と理解できるならそもそもこんなフレームワーク使わないし、理解したとしてもその上でそのスタイルと整合性の合うように別のスタイルを組み合わせたりするのはさらに難しい。そもそも汎用的なコードというのはあらゆる組み合わせの可能性を考慮して書かれているので、普通のコードよりも複雑になりがちである。
で、コードを読んだ上でそれでも意図がわからないルールがあったりする。親要素がネガティブマージンになっていて子要素のスタイルと組み合わせることでプラマイ０になるようなやつとか、そんなトリッキーなことをして何がしたいのかが分からない。ドキュメントを探しても書いてないし、 StackOverflow には同じところで詰まってる人がいる。結局「よく分からないけど親要素にボーダーをつけたら上にはみ出るからダメなんだ」と納得しないまま進むしかなく、とても気持ち悪い。
HTML がどんどん汚くなる
本当はこれを一番に書いても良かったんだけど、話の流れから結果的にここになった。でもこれは本当に言いたい。そもそも CSS はドキュメントの構造とスタイルを分離しようという思想なんで、HTML にスタイル指定をモリモリ書いていくのはおかしいという感覚は前からあって、それでも「いや頭のいい人たちが OOCSS とか SMACCS とか色々考えた結果こうなったのだから、これも必要悪か」と渋々従っていたのだが、それでも読みにくいものは読みにくい。じゃあ古き良き CSS というか HTML にはスタイルを全く書かずに意味だけを記述してやっていくかというと、それはそれで今度は CSS の方が大変になって SASS を使ってやれ継承だという話になりそうなので、それも避けたい。
思うに、汎用性の高さゆえにクラスの記述が爆発している。例えば、開発中のアプリではカラムの幅の持たせ方は１種類しかないにも関わらずフレームワークは４種類をサポートしていると、そのうちのどれかを選ぶためにクラスの記述が必要になる。それがパラメータの数だけ掛け算になって <div class="columns is-x"><div class="column is-a is-b is-c"> ...</div></div> のように 5, 6 種類のクラスの組み合わせでようやく思ったのに近いスタイルになるが、 CSS を自分で書いていいのであれば多分１種類でいい。100 種類のボタンが用意されていても実際にアプリで使うのが 3 種類なら、残りの 97 はノイズなのだから綺麗に視界から消えて欲しい。
クラスも多いがネストも多い。例えば次のように foo-child と bar を同居させて書きたい時に
<div class="foo">
<div class="foo-child bar">
<div class="bar-child">
</div>
</div>
</div>
これが何故かできなくて、次のようにネストさせないとスタイルが合わなかったりする。
<div class="foo">
<div class="foo-child">
<div class="bar">
<div class="bar-bar">
</div>
</div>
</div>
</div>
これが積もり積もって、頭の中では「２段にすればいいかなー」と思っていたら蓋を開けたら５段、６段になっていてゲッソリする。詳細は知らないが、これも汎用化するというフレームワークの指名ゆえに生まれた無駄だと思っている。
直感的でないレスポンシブの挙動
直感的かどうかというのは、主観的な話なのでその人のバックグラウンドによるんだとは思うが、ウインドウ幅を縮めた瞬間にガラッと見た目が変わってしまうのでやたらびっくりしてしまう。 Bulma なんかは、ちゃんとトップに「モバイルファースト」と大きく書いてあるので、それをあんまり気にせずにデスクトップファーストで作り始めた自分に非があるのは認める。だけど今までデスクトップファーストでしか作ったことないし、いきなり言われてもねというか、ブログとか簡単なサービスはいいとして高機能な UI を小さい画面で表現するのはかなりのデザイン力を要求されるし、なんかフレームワークを導入したから自動的にモバイル対応できましたにはならないと思う。
というわけで、ただでさえ設計力がいるんだけど、それはどの画面でどの UI を使うにしても常に考えていなければいけなくて、例えば「横に並べたいときはこのクラスあてりゃいいんだな」って思ってデスクトップサイズで開発してて、あとでモバイルサイズにしてみたらガッと縦になって「アイコン１個のために１行使うとかアホかー」になる。いやそれでも流石にレスポンシブフレームワークを謳うだけはあって、予想を裏切ってもそれなりに整った見た目にはなる。なるけどコレジャナイ感は拭えないし、何より自分で描いた覚えのない画面が急に出てくるのが気持ち悪いので最悪デスクトップと同じでもいいんじゃないかと思えてくる。
結局必要になるカスタム CSS
確かにフレームワークの方でカスタマイズできるように変数を用意してくれているので、ある程度はなんとかなる。けど、絶対にそれだけじゃ足りなくて必ず自前でなんらかの CSS は結局書くことになる。で、一度書き出すと「めっちゃ楽だ」ということに気づいてしまい、すぐに割れ窓になる。「こんなん横並びなんだから flex で済むだろ」でやってくと 100% 思い通りになる。で、気づくとレスポンシブがいつの間にか壊れている。既存のスタイルの何かと競合して壊れたんだろうが、面倒なので別のスタイルを上書きして直す。
あと大きいのが、デザイナーさんが居てくれる場合はほぼ 100% 自前のスタイルを書くことになるので、フレームワークがもともと用意したスタイルは最終的に影も形もなくなる。それは覚悟してるんだけどじゃあなんでフレームワークを使うかというと、苦手意識のあるレスポンシブをなんかよろしくやってくれるだろう期待があったりするんだけど、その期待は上で言った通り砕かれてしまった。変数も最初は「$danger がこの色で...」と当てはめていくだけなんだけど、そのうちに「薄い灰色よりももっと薄い灰色」とかが出てきて、最初は /* この部分は独自拡張 */ みたいにしていたけど、そのうちに独自拡張だらけになる。で、自分で CSS 書くを前提になると既存のスタイルがどんどん邪魔になってきて「なぜかスタイルが当たらない」と思うとだいたい優先度で負けていて !important をつけていくことになる。
この段階になると「半分くらいのスタイルがフレームワーク由来、残りはそれを上書きして拡張したものか完全に独自のスタイル」という状態になり、フレームワークと自前 CSS の境界がとても曖昧になる。HTML もフレームワーク由来のクラスと独自クラスが入り乱れて、非常に混乱してくる。
コードをすぐに参照できる場所に置いておきたい
フレームワークのコードは node_modules の奥深くに埋もれていていてなかなか目にする機会がないし、膨大なコードの中からアプリケーションで実際に使われているわずかな情報を抽出するのも難しい。100% 自分が意図して必要な分だけスタイルを記述して src 以下に置いておくのが、やっぱり一番コンパクトで良いのではないかと思う。「それができりゃ苦労しねえ！」って話なんだろうけど、トータルで見るとそのほうが辛くない気がする。
CSS フレームワークの概念自体が Bootstrap で広がったんだと思ってるんだけど、その頃から比べたら CSS はかなり進化しているし、少なくとも「何かしらの hack をしないと使い物にならない CSS 」ではなくなったと思う。 IE11 以上でよければ Grid も使える。ブラウザの差異を吸収するのは post css とかもやってくれるし、まあそもそもあまりマニアックな機能は使わないように気をつけていれば崩れないと思う。というわけで、臭い CSS に蓋をする役割としてはどんどん価値が減っていると思う。
ともかく辛さから逃れたい一心でフレームワークを削っていったら、HTML のネストはどんどん減るし、クラスも激減してコードも見やすくなった。それだけではなく、今まで微妙だなと思いながら放置していたスタイル崩れがどんどん解消していった。「フレームワークの流儀で書かなくてはいけない」という縛りプレイが悪い方向に働いて思うように書けなかったのと、HTML が複雑化してスタイルを直すのも困難だったことが原因だったと思われる。
何がいけなかったのか？
反省点としては、「とりあえず CSS フレームワークは導入しておけば楽になるだろ」という思考停止、「自分の書く CSS なんてたかが知れてるだろう」という自信の無さ、「自分が気づいていない何かをフレームワークがカバーしてくれるんじゃないか」という淡い期待を抱いてしまったことだろうと思う。確かにメディアクエリの知識とかは足りないんだけど、それはやりながら覚えればいい話。
自前で書くのは果たして楽なのか？
そんなことはないと思う。あと当たり前だけど CSS のスキルとコツが要る。ここではフレームワークを dis ってるんだけど、考え方は盗んだ方がいい。という意味では、やったこと自体は無駄にはなってないんだけど、ちょっと遠回りしすぎたねという感じ。地道に CSS スキルをつけていこうと思う。関係ないけど Grid 最高。
