TailwindCSS。一度は耳にしたことがある方も多いと思います。
これまでのフレークワークと何が違って何がいいのか？メリットと利用時の注意をこの記事でお伝えできればと思います！
導入検討の際のお役に立てば嬉しく思います。
【こんな方にオススメ！】
・CSSフレームワークの導入を検討している方
・これからTailwindCSSを勉強しようとしている方
また、一個人の考え方なので何かご意見があればコメントいただけると幸いです。
TailwindCSSは何がいいの？
最大の特徴は「utility-first」のCSSフレームワークだということです。
utility-firstというのは汎用的なclassを定義して組み合わせることでデザインパーツを構築する考え方のフレームワークです。
他のCSSフレームワークと何が違うの？
例えば、BootstrapたBulmaはコンポーネントとしてスタイルが定義されているのでclassでcardを付与するだけでカードデザインが適用されます。
しかし、TailwindCSSはコンポーネントという概念はなく、細かく定義されたutilityのclassを組み合わせることでcardデザインを実現させます。
<!-- Bootstrap -->
<div class="card">
<div class="card-body">This is card.</div>
</div>
<!-- Bulma -->
<div class="card">
<div class="card-content">This is card.</div>
</div>
<!-- TailwindCSS -->
<div class="max-w-sm rounded overflow-hidden shadow-lg">
<div class="px-6 py-4">This is card.</div>
</div>
使うための環境セットアップ
導入については公式サイトを見ながらセットアップしてもらえれば問題ないと思います。
個人的にハマった点はJavaScriptで動的に生成する場合の設定でした…
動的に生成したHTML要素のTailwindCSSはwebpackでコンパイルした後にユーザーの操作によって追加されます。
なので、コンパイル時点でのCSSに反映されません。
TailwindCSSは指定したファイルを解析して必要なclassのみをスタイルとしてコンパイルしたすごい機能があります。
具体的には、classの指定から消せば、コンパイルの時に自動で不要なclassを削除してくれます…感動でした。
JavaScriptで生成するHTMLにTailwindCSSのclassを指定している場合はJSファイルも解析対象にしてあげましょう。
tailwind.config.jsに追記することで可能です。
module.exports = {
- content: ['./index.html'],
+ content: ['./index.html', './src/script/common.ts'],
theme: {
extend: {}
},
variants: {
extend: {}
},
plugins: []
};
classをマルチクラスで記述するのが面倒だ…
これまでCSSをいろんなフレームワークや設計で記述された方なら絶対思うはずです…。（私も思いました）
やっぱシングルクラスでしょ！って私も考えていましたが、TailwindCSSでは諦めていただければと思います。
理由はシンプルに従来のCSSフレームワークと同じになり、コンポーネントを管理しないといけなくなるからです。
平たく言えばTailwindCSSのメリットがなくなります。
サービス改善で発生するパターン違いをどうするのか都度議論が発生し、それを怠るとコンポーネント崩壊が始まり手がつけられない状態になります。
公式サイトにもあるので、もしコンポーネントで管理したいということであれば別のフレームワーク、CSS設計を導入して独自で設計することをオススメします。
実はシングルクラスにもできるけど、やめた方がいい
@applyでclassをまとめることでコンポーネントのように定義することはできます。
繰り返しになりますが、TailWindwCSSではBadケースとなるのでやめることをオススメします。
詳細は別の投稿にまとめてあるのでそちらをご覧ください。
classが覚えられないかもしれない…
vscodeであればプラグインがあるので活用してもらえればそこまで心配しなくても良いと考えています！
TailwindCSSを利用する際はぜひ入れてください！（私は知らず、初期は効率悪く作業してしまってました…）
【まとめ】乗り遅れた人のためのTailwindCSS
TailwindCSSはマルチクラスで冗長的な感じは否めないですが、柔軟に対応できる今の時代にあったフレームワークなのではないかと考えています。
スタートアップでどんなサービスにでも変化できる状態だと、どれだけCSSの設計を作り込んでも10年後には崩壊していることは発生すると考えています。
ならば初めから設計のコストをカットして、サービスの方針や土台が固まるまでは柔軟に対応できるフレームワークを導入する方が良いというのが私の考えです。
導入する場合には破壊的変更に注意する
tailwindcssは流行りのフレームワークのためか更新スピードが早いです。
TailwindCSSに限ったことではありませんがバージョンが上がったからといってメジャーアップデートに対応すると破壊的変更がされていた場合アップデートは容易ではありません…。
そのまま使い続けるのでも良いのですが、古いバージョンになれば新しく便利なメソッドを使えなくなるので、
それだけで技術的負債となり数年後には目も当てられないような状況になっていることはほぼ間違いないです。
フレームワーク導入を検討するなら同時にメンテナンス工数も加味して計画を立てられることを強くオススメします！
フレームワークの導入はその後のメンテナンスコストも加味して検討するべきだと考えます。