こんにちは！tailwind.cssを導入したら結婚できました。Mizutani(@sirycity)です。

tailwindを導入して数ヶ月、自分の手応えや周りの反応から、CSSフレームワークを導入する際に「こういうケースではtailwindを導入した方が良い」「こういうケースではやめといた方が良い」ってのが徐々に分かってきたので備忘録を兼ねて書いてきます。

向いているケースと向いてないケースを羅列していくぜ。

向いている:フロントエンドが厚い構成, 向いていない:バックエンドが厚い構成

これ大事。これが一番の条件な気がします。より具体的に言うとReact系、Vue系、Angular系を採用しているか否かです。いわゆるモダンフロントエンド。なぜなら…

モダンフロントエンドのエコシステムにロックインしている

tailwindはnpmでの読み込みをほぼ前提としています。cdnでも読み込めるんだけど公式が推奨していない。

これはcdnでの読み込みがベストプラクティスと化しているCSSフレームワークとは一線を画しています。

語弊を恐れず言うならば、npmすら使ってないレガシーフロントエンドはこっちから願い下げだくらいのテンションです。

また、tailwindは軽そうな名前の割にファイルサイズが大きくそのまま読み込むのはあまりよろしくないです。

このため、実際はpurgecss(パージCSS、使ってないCSSを消すやつ)やpostcssと一緒に使われるケースが非常に多いです。

この辺の環境構築をフロントエンドのエコシステムなしで作るのは修羅の道です。そういう意味でも、tailwindはモダンフロントエンドに向いていると考えます。

向いている:フロントエンド周りが少数精鋭, 向いていない:フロントエンド周りが分業

初期導入に時間がかかる

tailwindは上述の通り導入までに時間がかかります。cdnで数行追加すれば使い始められるbootstrapとはわけが違いますわ。

tailwindが爆速になってくるのはある程度開発が進んでからです。したがって、初期導入をスピーディにこなせるスキルのある人員がいないと導入はなかなか難しい…

写経は苦手

tailwindの苦手なことの一つとしてデザインカンプの丸写しがあります。まあこれはCSSフレームワーク全般に言えるかもしれんけど、1px単位の微調整にはすごく不向きです。

デザイナーとコーダーとフロントエンドエンジニアが分業されていて、かつデザインカンプから始まるみたいなかっちりした構成のチームには不向きな気がする…

逆にフロントエンド周りが少数精鋭で、デザインからフロントエンド開発まで同じ人が行うような構成ならtailwindはうってつけです。

結論

ここまでダラダラと書きましたが、tailwindが向いているか向いていないかはこの一言で判断できる気がします

今どきか

以上。ベンチャー企業とかと相性めっちゃ良さそうなので、起業する際はぜひtailwindをご贔屓に(？)