過去5年間、私は主要なAtomic CSS（Utility-First CSS）フレームワークを深く使い込んできました。技術スタックは最初のTailwind CSSから始まり、パフォーマンスを考慮してWindi CSSへ移行し、Windiのメンテナンス終了後はUnoCSSへ乗り換え、そして現在、再びTailwind CSSに戻ってきました。
一見すると単なる循環のようですが、実際には各移行にはそれぞれ独自の価値がありました。
2021年：Tailwind CSSとの出会い
当時の私はまだ従来のCSSを書いており、classの命名に悩まされていました。Tailwindを発見した時、いくつかの特徴に心を惹かれました：
開発速度の劇的な向上
CSSとHTMLを行き来する必要がなくなり、「一度しか使わないカード」のために完璧なclassNameを考案する必要もなくなりました。これが私にとって最大のメリットでした。
デザインシステムによる制約
theme.config.jsでデザイン仕様（スペーシング、カラー、フォント）を事前に定義することで、デザインの一貫性が保たれます。提供される規約を使えば、スタイルの混乱はほぼ起こりません。
予想外の保守性の高さ
当時多くの人が「CSSをクラス名として書くと保守性が下がる」と考えていましたが、私の実感は正反対でした。数ヶ月後にコンポーネントを修正する際、CSSファイルを読み返す必要がなく、HTML構造上のclassを見るだけでスタイルが明確に把握できます。長すぎるclassは改行やコンポーネント化で最適化できます。
使い始めは常にドキュメントを参照する必要があり、むしろ進捗が遅くなりました。しかし約1週間で基本的な使い方を習得し、効率が大幅に向上しました。
2021年：WindiCSSへの移行 —— パフォーマンスの追求
プロジェクトが深まるにつれ、初期のTailwind（JITエンジン登場前）のパフォーマンスボトルネックに直面しました。
開発モードでは、Tailwindはすべての可能なユーティリティクラスを含む巨大なCSSファイル（通常数MB）を生成していました。これにより以下の問題が発生：
-
コールドスタートの遅延 ——
npm run dev実行後、長時間の待機が必要 -
ホットリロードの遅延 ——
tailwind.config.jsを変更するたびに、HMRに数秒以上かかる
そんな時、Windi CSSが登場しました。最大の革新はオンデマンド生成（On-demand Generation）：実際に使用されるクラス名のCSSのみをリアルタイムで生成し、事前にすべてのルールを生成することはありません。
速度は桁違いに向上し、体験は素晴らしく、Tailwind APIとほぼ100%互換性がありました。私は即座に移行を実行しました。
2022-2023年：UnoCSS採用 —— 究極のパフォーマンスと革新
WindiCSSを使用してしばらく経った頃、突然メンテナンス終了が発表されました。理由はTailwindのパフォーマンスが改善されたからとのこと。その時、UnoCSSが私の視界に入りました。
作者が公開したパフォーマンス比較（2021年）：
10/21/2021, 2:17:45 PM
1656 utilities | x50 runs
none 8.75 ms / 0.00 ms
unocss v0.0.0 13.72 ms / 4.97 ms (x1.00)
windicss v3.1.9 980.41 ms / 971.66 ms (x195.36)
tailwindcss v3.0.0-alpha.1 1258.54 ms / 1249.79 ms (x251.28)
パフォーマンス以外にも、UnoCSSには目を引く2つの機能がありました：
Attributifyモードでより見やすいコード構造に：
<button
bg="blue-400 hover:blue-500 dark:blue-500 dark:hover:blue-600"
text="sm white"
font="mono light"
p="y-2 x-4"
border="2 rounded blue-200"
>
Button
</button>
純粋なCSSアイコンソリューション：
<!-- Phosphor iconsのアンカーアイコン -->
<div class="i-ph-anchor-simple-thin" />
<!-- 大きなVueロゴ -->
<div class="i-logos-vue text-3xl" />
<!-- ライトモードで太陽、ダークモードで月を表示 -->
<button class="i-carbon-sun dark:i-carbon-moon" />
極めて柔軟なアーキテクチャ設計と、作者のAnthony Fu氏への敬意もあり、最終的にUnoCSSを選択しました。
2024-2025年：Tailwindへの回帰 —— エコシステムの力
Tailwind 4.0のリリースで状況が変わりました：
- パフォーマンス問題が大幅に改善（Rustで書かれたLightning CSSを採用）
- WindiCSSとUnoCSSの優れた機能を吸収
- 開発体験が質的に向上
しかし、私を本当に回帰させたのはエコシステムの成熟度でした。Tailwindはデファクトスタンダードになっています：
- 多くのUIフレームワークがTailwindをデフォルトサポート
- 公式コンポーネントライブラリ（Tailwind UI、Catalyst UI）の充実
- ツールチェーンの完成度（Prettierプラグイン、VSCode拡張など）
- チーム採用とコラボレーションコストの低減
UnoCSSを使い続けるには様々なプラグインでの互換性対応が必要で、一部のフレームワークは公式にTailwindのみをサポートしています。プロジェクト開発の観点から、エコシステムの問題は無視できません。
振り返りと考察
技術移行タイムライン
2021年: Tailwind 2 → WindiCSS
主な価値：開発体験の向上
WindiCSSのオンデマンド生成により、ホットリロードが数秒からミリ秒単位に短縮。この革新がTailwind 3のJITモード導入を直接促しました。
2022-2023年: WindiCSS → UnoCSS
主な価値：パフォーマンスの極限化とアーキテクチャの柔軟性
ビルド速度がさらに数倍向上し、プリセットシステムにより異なるデザインシステムの混在使用や独自のアトミックルール作成が可能に。
2024-2025年: UnoCSS → Tailwind 4
主な価値：エコシステムの成熟とチームコラボレーション
Tailwindがデファクトスタンダードとなり、v4でパフォーマンスも遜色なくなり、エンタープライズプロジェクトの最適解に。
この経験の価値
一周回って原点に戻ったように見えますが、このプロセスは決して無意味ではありませんでした：
WindiCSSとUnoCSSとの競争がTailwindの革新を直接促し、現在のTailwind 4はWindi（JITモード）とUnoCSS（より高速なエンジン、純粋CSSアイコンなどの概念）の多くの利点を吸収した「集大成」となっています。
また、私が新しいツールを次々と試せた理由は主に2つあります：
- Atomic CSSツール間の移行コストが低く、構文の互換性があり、探索のコストが小さい
- 新規プロジェクトで試すため、チームメンバーが不慣れでも従来のCSS記述方法で対応可能で、進捗に影響しない
この旅はAtomic CSSエコシステムの完全な進化サイクルを目撃する機会となり、各選択はその時点での最適解を追求した結果でした。
参考リンク：