CSSフレームワーク・ライブラリーを使うなら自前でCSSを書くな！という話
どうも過激派のめろたんです。
タイトル通りで僕はそういうお気持ちで日々過ごしております。
ではなぜそうおもっているのか等々を書いていこうと思います。
なぜそうおもうか。例を添えて
なぜかと言うと、大体腐るからです。クソ雑に言ってるのではて？となるかもしれませんが、僕の語彙ではそういう風にしか表現できない。
まあ実際に例をあげていろいろ書いてみる。
あなたはWebアプリを作っています。 Bootstrapを使っているとしましょう。
便利だよね。わかる。
で開発が進むに連れて、大きいボタンがほしくなりました。
btn-lg のものよりもっと大きいものです。
なおbtn-lgは使っておりません。
ではここでどうしますか？
btn-lgのスタイルを上書きする？btn-more-lgみたいなのをつくる？- そのページだけ
btn-lgのサイズを変えるようにする？
このどれかが取られる選択肢かなぁと思います。それか <button style="width:....."> とか直で書いちゃうとかかな？
まあ直で書いちゃうのは無いでしょ。というので一旦捨て置いて。 では個々に問題を考えていく。
1. btn-lg のスタイルを上書きする？ の例
まあ単純に元の btn-lg の大きさで使いたい場合が出てきたときに死ぬよね。
一人で死ぬならまだしも、チーム開発で他メンバーが「Bootstrap使ってるし btn-lg ってのでいい感じの大きさのボタンできるじゃ〜ん。」っていってBootstrapのドキュメント通りに書いたら全然違う結果になった！っていうのが余裕で起こる。
更にここで、どうやってもとの btn-lg を使おうか…となったときに、 btn-origin-lg とか書く？それとも気合で元にもどす？そのときにどこまで影響あるかわかる？この場合おそらく width と height だけだと思うけど、 line-height 等を使っていた場合どうなるかわかる？
などなど。諸問題が連なって発生する。
ヤバイわよ！
2. btn-more-lg みたいなのをつくる？の例
1の問題は起きない。 可能性が高い 。 バリエーションを増やすと、あれもこれも。となりがち。故に今度はもうちょっと小さいやつがほしい。一番小さいやつよりもっと小さいやつがほしい。そもそも角丸がいらない。真円のボタンが。中にいい感じにアイコンをいれたい。etc
という風になりがち。
結果、どれがBootstrapのものなのか、どれが自前のものなのかわからなくなり死にがち。
ドキュメントに無いぞ！ってなってなにこれ…ってなるやつ。
一人ならわかるかもだけど、チーム開発で…（以下略。
ドキュメントに無いので、書いて良いんだな。となりどんどん書かれる。ちょっとしたスタイル(すこしマージン開けたいとか)がどんどん書かれていく。 結果さらになにがなにかわからなくなる。
ヤバイわよ！
3. そのページだけ btn-lg のサイズを変えるようにする？の例
body.a-page .btn-lg { }
みたいな書き方のやつね。
これは 1 と 2 の似たような問題が合体して押し寄せてくる。
画面によってバリエーションが発生する。
「このページのこのボタンこのサイズなんだ〜他のページでも同じように使えばいい感じになるかな？」とやってもならない。結果 body のところの指定が増えるまたはそのページの body に .a-page クラスがつく。
本当なら .a-page だけのスタイルがここに入ってくるはずなので、 .a-page のアレのスタイル変えよ〜とかなったときに別のページも影響して死ぬ。しかも普通は気付け無い。
ドキュメントに書いてあるが、違う見た目になる場合がある。という地獄のサムシングが爆誕して治安が無になる。 結果死ぬ。
またこれは詳細度が上がる書き方なので、詳細度・ド・バトル が開催され下手をすると !important 先輩が登場する。
結果死ぬ。
ヤバイわよ…。
そして全てに共通する問題
フレームワークのアップデートで死ぬ可能性が限りなく高い。
たとえばBootstrap4はjQueryに依存しているが、5になるとjQueryが要らなくなる。
即座にアップデートしたいであろう。
ところが、上記のような自前CSSを書いていた場合、意図していないスタイルの崩れが発生しうる。
このときに上の例のボタンの大きさを〜というくらいなら良いかもだが、もしレイアウト系のスタイルを触っていた場合どうだろうか？
container や row 等をいい感じにしたいんだよね〜等で少し触っていた場合、本当に全体に影響がでる。
これらをアップデートしたときに果たしてどうなるのか。
実際に一つ前のバージョンのBootstrapをみると、明らかに色々違う。
レスポンシブ対応が逝く。そもそもクラス名が変わってしまい、何もいじっていなければエディターで一括置き換え等すればいい感じになったかもしれないところが、不要なところまで変わって辛いことになる。等々
色々起きる可能性がある。
これらの問題に関して、「うまく設計し立ち回れば問題ないでしょう。」という意見があるだろうが、それができるならそもそもCSSフレームワークつかうなよ！！！！(過激派
どうすべきと考えているか
です。
こうすれば諸問題は起こり得ないですね。(過激派
真面目な話をすると、
CSSフレームワークを使う際はSCSS等のいわゆるaltCSSを使って必要なものだけをとってきて使うようにする。
最近のものなら各種変数があるはずなのでそれをよしなに変更して、変に別クラスを作るとか上書きをするとかしないようにする。とかかな。
そうすれば概ね問題は回避できるんじゃねえかな…。しらんけど。なぜなら僕はフレームワーク使うなよ勢なので。
あとはTwitterで話してたんだけど
最近は困りそうな時には間をとってcssフレームワークとtailwindをどっちも入れたらどうか、という落としどころに、、、笑
— nabettu🍲個人開発 (@nabettu) 2020年5月2日
こういうのはありかとおもった。
Tailwindはユーティリティ集のようなCSSフレームワーク(?)で、各種CSSのスタイルの宣言がクラスで書かれている。
mt-4とかだと「上のマージンをサイズを4で取る」というスタイルになる。(サイズ1が0.25rem。その4倍なので1rem。)
このようなクラスがザラーーーーーーーっと大量にある。
自分で書くよりよっぽど安全であろうと思う。
優先度とかは気をつける必要があるが、まあそれくらいだろう。
自分でかいて変に上書きしたり、ドキュメントにありそうな名前で作りあとで混乱したり、変に詳細度を上げてしまい意図しない崩壊が起きたり等は防げるはず。
フレームワークを使っていて、どうしても少し変えたいとかがあればTailwindをおすすめする。
自分で書いてるならTailwind入れなくてもいい。書けばいいんだから。クラスに書くかCSSを書くかの違いでしかないからね。
まとめ
CSSフレームワークを使っているなら自前でCSSを書くな！今の自分が良くても半年後の自分・一週間後の同僚等々が悲しい気持ちになるぞ。
覚悟完了しているならば書いてもよし。
どうしてもちょっと変えないといけない等あれば Tailwind の導入を考えよう。
絶対に自前でCSSを書くなよ！
死ぬぞ！
