このサイトのスタイルを、純粋なCSS運用からTailwindCSS + DaisyUIベースへ移行しました。

結論、ブログサイトとして視認性のいいシンプルな見た目になって満足しています。

比較画像

ホーム

旧

新

ブログ一覧

旧

新

ブログ詳細

旧

新

純粋なCSSは設計することが多すぎる

純粋なCSSを真面目に運用していくと、結局CSSフレームワークを自作しているのと変わらなくなる。

最初は普通にCSSを書いていました。

.card {
  padding: 16px;
  border-radius: 12px;
  border: 1px solid #000;
  background: white;
}

もちろん最初はこれで十分です。

しかし、画面数やコンポーネントが増えていくと、徐々に「ルール」が欲しくなってきます。

例えば、

• トークン設計
  • spacing（margin / padding基準）
  • color（テーマ・ダークモード含む）
  • radius / shadow / typography
• コンポーネント設計
  • variants（button, card等のバリエーション定義）
  • state（hover, focus, disabledの統一）
• レイアウト設計
  • レスポンシブの方針（breakpoint・単位の統一）
• CSS設計ルール
  • 命名規則
  • 責務分離（何をどこに書くか）

など。

やればやるほど考えることが増えていって、無限に増え続ける設計を前に絶望します。

その結果、「TailwindCSSやDaisyUIでいいや」となります。

個人開発でやるにはコストが高すぎる

もちろん、「自前CSSフレームワークを作る」こと自体は悪くないです。

設計コストや開発コストを払ってでも、そのほうが長期的に得ならやればよいと思います。

ただ、個人開発の範疇だと、かなり割に合わないと感じました。

新しいUIを作るたびに、

• ユーティリティを追加するか？
• コンポーネント化するか？
• variantを増やすか？
• 例外CSSで逃げるか？

みたいな判断が発生して、かなり消耗します。

移行してよかったこと

意思決定が減った

フレームワークのユーティリティクラスを使えば、追加も削除も躊躇する必要がありません。デザイントークン設計を自分でやる必要がなく、p-4やtext-base-contentのような既存の語彙に乗れるのが楽です。

最低限の見た目が担保される

DaisyUIではbtnやcardといったクラス一つで、それなりに整ったUIが出来上がります。ゼロからhover状態やfocus-visibleを書かなくていいのは、地味に大きいです。

気になった点・注意すること

クラス名が長くなる

TailwindCSSの宿命として、HTMLにクラスが並ぶため実装が長くなります。 気になる人はすごい気にするやつですね。

私もはじめは気になっていましたが、だんだんと慣れてきたのとあまりに実装が楽になるので気にならなくなってきました。

フレームワークっぽさが残る

当然ながら、そのまま使うとかなり「DaisyUIっぽさ」が出ます。

細かいカスタマイズをしようとすると、DaisyUIのデフォルトを上書きする必要があり、完全にコントロールしたい箇所は、素のTailwindCSSで書いたほうがいいこともあるかもしれません。

まとめ

個人ブログを純粋なCSSからTailwindCSS + DaisyUIへ移行して、デザインを刷新しました。

個人的にはシンプルで見やすいサイトに生まれ変わったなと思っています。

純粋なCSSを突き詰めるのも面白いですが、個人開発では、

「いい感じの見た目を、ほどほどのコストで得る」

ことの価値はかなり大きいと思いました。