Tailwind CSS v4.0 リリース

 (tailwindcss.com)
1 ポイント 投稿者 GN⁺ 2025-01-24 | 1件のコメント | WhatsAppで共有
  • Tailwind CSS v4.0は、フレームワークをゼロから書き直したリリースで、ビルド性能を大幅に高め、設定・カスタマイズの流れをCSS中心へと変えるもの
  • Catalyst基準のフルビルドはv3.4の378msからv4.0の100msへ3.78倍高速化し、新しいCSSがないインクリメンタルビルドは35msから192µsへ182倍改善
  • インストールは@import "tailwindcss"の1行と設定不要のデフォルトでシンプルになり、ViteユーザーはPostCSSの代わりに@tailwindcss/viteを使える
  • v4.0はcascade layers、@property、color-mix()、logical propertiesのようなモダンCSS機能を活用し、コンテンツの自動検出と組み込みの@import処理を導入
  • コンテナクエリ、3D transform、拡張されたgradient API、@starting-style、not-*、field-sizing、color-scheme、inertなどがコア機能に入り、別途プラグインへの依存が減少

ゼロから書き直した高性能エンジン

  • Tailwind CSS v4.0は、数年にわたるアーキテクチャ経験をもとに、フレームワークをゼロから再実装したバージョン
  • 自社プロジェクトのベンチマークでは、フルリビルドは3.5倍以上、インクリメンタルビルドは8倍以上高速化
  • Catalyst基準の中央値ビルド時間は次のとおり
    • フルビルド: v3.4 378ms → v4.0 100ms、3.78倍改善
    • 新しいCSSがあるインクリメンタルリビルド: 44ms → 5ms、8.8倍改善
    • 新しいCSSがないインクリメンタルリビルド: 35ms → 192µs、182倍改善
  • 新しいCSSをコンパイルする必要がないインクリメンタルビルドは100倍以上速くなり、マイクロ秒単位で完了する
    • プロジェクトに長く取り組むほど、flex、col-span-2、font-boldのようにすでに使ったクラスを再利用することが多くなり、こうしたビルドに頻繁に遭遇するようになる

モダンCSSプラットフォームの活用

  • v4.0は、Tailwind CSS v3.0以降に進化したWebプラットフォーム機能を積極的に活用
  • 主な基盤CSS機能は次のとおり
    • Native cascade layers: 異なるスタイルルールが相互作用する方法をより細かく制御
    • Registered custom properties: gradientアニメーションを可能にし、大規模ページで性能を大きく改善
    • color-mix(): CSS変数とcurrentColorを含む、あらゆる色値の不透明度を調整できる
    • Logical properties: RTL対応を単純化し、生成されるCSSサイズを削減
  • これらの機能はTailwind内部の実装も単純化し、バグの発生面を減らして保守を容易にする

インストールとビルド統合の単純化

  • インストール手順は、ステップとボイラープレートを減らす方向に整理
    • npm i tailwindcss @tailwindcss/postcss
    • PostCSSプラグインに@tailwindcss/postcssを追加
    • CSSファイルで@import "tailwindcss"を使用
  • v4.0では、@tailwindディレクティブの代わりにCSS 1行でTailwindを取り込んで使える
  • テンプレートファイルのパスを含め、何も設定せずに始められる設定不要のフローを提供
  • 別途外部プラグインなしで@importルールをバンドルし、vendor prefixingとモダン構文変換にはLightning CSSを内部的に使用
  • ViteユーザーはPostCSSの代わりに@tailwindcss/viteを選択できる
    • Tailwind CSS v4.0はPostCSSプラグインとしても高速だが、Viteプラグインを使うとより良い性能が得られる

コンテンツ自動検出と組み込みimport

  • v3で必要だったcontent配列設定は、v4.0の自動検出ヒューリスティックに置き換えられた
  • .gitignoreにある項目は自動的に無視し、依存関係やバージョン管理されていない生成ファイルをスキャンしない
    • 例: /node_modules、/coverage、/.next、/build
  • 画像、動画、.zipなどのバイナリ拡張子も自動的に無視
  • デフォルトで除外されるソースを明示的に追加する必要がある場合は、CSSファイル内で@sourceディレクティブを使用できる
    • @source "../node_modules/@my-company/ui-lib";
    • @sourceも同じヒューリスティックを使うため、バイナリファイルタイプは別途拡張子を指定しなくても除外される
  • v4.0以前は、別のCSSファイルを@importでインライン化するにはpostcss-importのような別途プラグインが必要だったが、現在は組み込みimport対応により他のツールは不要
    • importシステムはTailwind CSS専用に作られており、エンジンと密接に統合されているため、より高速に動作する

CSS-first設定とtheme variables

  • v4.0の大きな変更の一つは、プロジェクト設定をJavaScriptではなくCSSで直接行う方式
  • tailwind.config.jsファイルの代わりに、TailwindをimportするCSSファイル内で@themeを使ってカスタマイズできる
    • デザイントークン設定
    • カスタムユーティリティ定義
    • カスタムvariant定義
  • @themeに定義したデザイントークンは、デフォルトでCSS変数として公開される
    • 例: --font-display、--breakpoint-3xl、--color-avocado-500、--ease-fluid
  • こうして生成されたCSS変数は、ランタイムで通常のCSSとして参照できる
    • インラインスタイルの再利用
    • Motionのようなライブラリに渡してアニメーション処理

動的ユーティリティ値とvariant

  • v4.0は、複数のユーティリティとvariantが特定の任意値を設定なしで受け取れるよう単純化
  • gridは別途設定なしで望むサイズを使える
    • 例: grid grid-cols-15
  • カスタムboolean data attributeも、事前定義せずにターゲットにできる
    • 例: data-current:opacity-100
  • px-*、mt-*、w-*、h-*のようなspacingユーティリティは、単一のspacing scale変数から動的に派生
    • 例: --spacing: 0.25rem
    • w-17はcalc(var(--spacing) * 17)の形で生成される
  • v4.0とともに登場したアップグレードツールは、不要になった任意値構文を検出すると、多くの場合自動で単純化する

カラーパレットとコンテナクエリ

  • デフォルトのカラーパレット全体がrgbから**oklch**へアップグレード
    • sRGB色空間の限界を超え、より広いgamutを活用して色をより鮮やかにする
    • v3との色のバランスは維持しようとしているため、既存プロジェクトのアップグレード時にbreaking changeのようには感じられないはず
  • コンテナクエリ対応がv4.0でコアに入り、@tailwindcss/container-queriesプラグインが不要になった
  • 新しい@max-* variantでmax-widthコンテナクエリを使える
  • 通常のbreakpoint variantのように@min-*と@max-*を重ねて、コンテナクエリの範囲を定義できる

3D transformとgradient APIの拡張

  • v4.0は3D transform向けAPIを追加
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • gradient機能も拡張され、カスタムCSSなしでより多様な効果を作れる
  • linear gradientは角度を値として受け取れる
    • 例: bg-linear-45
    • 既存のbg-gradient-*はbg-linear-*に名称変更
  • gradientの色補間モードはmodifierで制御できる
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • v4.0のデフォルト補間はOKLABで、他の色空間modifierも使用できる
  • 新しいbg-conic-*、bg-radial-*ユーティリティでconic・radial gradientを作れる
    • 既存のfrom-*、via-*、to-*と連携して動作
    • 色補間方式を設定するmodifierと、gradient位置などの詳細制御のための任意値サポートを含む

新しいvariantとユーティリティ

  • 新しいstarting variantはCSS @starting-styleをサポート
    • 要素が最初に表示されるときにプロパティtransitionを作れる
    • JavaScriptなしでページに現れる要素をアニメーション処理できる
    • ブラウザ対応はまだ多くのチームにとって十分ではないかもしれないが、近づきつつある
  • 新しいnot-* variantはCSS :not() pseudo-classをサポート
    • 例: not-hover:opacity-75
    • media queryと@supports queryも否定できる
  • v4.0には次のユーティリティとvariantも追加
    • inset-shadow-*、inset-ring-*: 単一要素に最大4つのbox shadowレイヤーを重ねられる
    • field-sizing: JavaScriptなしでtextareaの自動サイズ調整をサポート
    • color-scheme: dark modeで明るいscrollbarを取り除ける
    • font-stretch: さまざまな幅をサポートするvariable fontを調整
    • inert: inert属性で示された非インタラクティブ要素をスタイリング
    • nth-*: nth系のスタイリングをサポート
    • in-*: groupクラスなしでgroup-*に似た動作をする
    • :popover-open: 既存のopen variantで開いているpopoverもターゲットにする
    • descendant variant: すべての子孫要素をスタイリング

始め方とアップグレード経路

関連記事

1件のコメント

 
GN⁺ 2025-01-24
Hacker News の意見

  • かつて Tailwind のさまざまな欠点や、実際には現代的な「純粋な」Web のやり方との非互換性を強く批判していたが、v4 の大きな前進はとても喜ばしい
    Tailwind のテーマにネイティブ CSS 変数としてアクセスでき、ドキュメントには外部スタイルシートでネイティブ変数を使って書いたボタンコンポーネントの例まであるのは、ものすごい変化だ
    CSS だけで設定できるのも素晴らしく、いまや Tailwind は合理的なアーキテクチャを飲み込んでしまう JavaScript 的な「バイラル」フレームワークではなく、どんなプロジェクトにも追加できるユーティリティのように感じられる
    ここ数年の批判が効いたのか、自ら良い結論にたどり着いたのかはともかく、Tailwind 賛否論争のかなりの部分は今ではあまり関係がなくなったように見え、それは非常に良いことだ。これでプロダクト作りに集中できる

    • 実際に使う面では今も批判的だが、Tailwind が AI 生成ワークフローによく合う点には驚かされる
      何でも体系的に表現できるので本当にうまく機能し、そこには非常に有用な何かがある
    • Tailwind 賛否論争がもはや関係ないという点には同意しにくい。デザイナー／デザインエンジニアとしては 2 つの問題がある
      第一に、JavaScript/Tailwind エンジニアがデザインの議論を支配してしまった。「ユーティリティファースト」「未使用コードの削除」「型安全な CSS」よりも、デザインシステム、たとえばタイポグラフィで Perfect Fifth を使うか Perfect Fourth を使うかといった問題にもっと集中するべきだ
      第二に、Tailwind は実際の制作プロセスに参加しにくくしている。デザイン上の決定が flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)] のような難解な React コンポーネント表現の中に埋もれてしまう
      JavaScript エンジニアには理解できるかもしれないが、体系的なデザインにとっては障壁になる。CSS で精密な数学的関係を表現する代わりに、より手軽なインラインスタイルを使っているようなものだ
    • Tailwind CSS のカラーパレットだけが欲しい

  • CSS は以前よりずっと使いやすくなり、ほとんどのブラウザも今では一貫して動作する
    ビルドステップが不要で、過剰なコードでマークアップを散らかさないので、学ぶ価値がある
    HTML の中に style 属性を直接書くこともできるが、以前は関心の分離のために避けられていた。なのに、なぜ似たような方式をまた導入しようとするのか不思議だ。単に数文字減らしたいだけなのかと思ってしまう
    style 属性なら頭の中でコードを変換する必要もないので、むしろより直感的に見える。魅力がよく分からない

    • style 属性ではできないことがかなりある。たとえば疑似クラス :hover、:focus、疑似要素 ::before、::after、メディアクエリ、キーフレームとアニメーションがある
      大規模プロジェクトでは開発者体験も良くない
      一方で、まもなく標準になる @scope は、スタイルを近くに配置するための良い追加機能だ: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • 最近の Tailwind は、CSS クラスの代わりに抽象化レイヤーとして機能するコンポーネント抽象化システムと併用されることが多い
      コンポーネント抽象化は、意味とスタイルをより強く分離してくれる。どちらの場合も「hero」という抽象化を探す必要があるが、コンポーネントの世界ではスタイルだけでなく HTML タグ名まで抽象化する
      いずれにせよ「スタイルの詳細」は、ページのソースファイルである「コンテンツ」から分離されている。関心の分離、つまりコンテンツと表現のより良い分離のためなら、ビルドステップを受け入れられる
    • 魅力は、CSS クラス名を考える必要がなく、HTML と並んでいるので読みやすく、命名方式が標準化されていてどこでも同じルールを使えることにある
      別ファイルを管理したり、使っていないコンポーネントを削除したりする必要も減る
      style タグではできなかったメディアクエリを使え、他の場所で使っているクラスを変えてしまうリスクもない。CSS のグローバルスコープには利点もあるが危険でもある
    • React との強い結合をあまりにも当然のものとして受け入れるようになった結果だ
      スタイルはデザインシステムではなくコンポーネントに属すると見なされる。JavaScript ファーストのエンジニアリングエコシステムには、現代 CSS と体系的デザインの力を知るデザイン主導の会社がもっと必要だ
    • 大規模プロジェクトで扱うファイル数を考えると、Tailwind はかなり魅力的に見える
      通常の .css 方式では、奇妙な名前、重複、衝突の可能性が生じる。css modules も選択肢にはなるが、コンポーネント／ページごとのファイル数が実質的に 2 倍になる
      sass や less は、css modules と通常の .css の問題を一緒に混ぜたように感じる
      Tailwind を本質的に好きでも嫌いでもないし、最初は大嫌いだったが、コンポーネントとページで構成される200 ファイル以上のプロジェクトでは価値を感じる

  • Tailwind に対する最初の反応は「面倒くさい」だった。CSS はすでに知っているのに、今度は CSS をもう一度学び直さないといけないような感じだった。
    親が子どもの数学の宿題を手伝おうとしたら、学校で習うやり方が昔とまったく違っていて、自分の解き方は今でも正しいのに受け入れられず、子どもは2つの体系をすり合わせるのにイライラしている状況に似て見える。
    チームでうまく機能し、スケールもしやすいので、とにかく使うべきだという雰囲気は理解できるし、実際に経験もした。
    それでもやはり、クラスやタグを対象にする普通のスタイルシートのほうが好きだ。特に CSS が今ではネストしたセレクタをサポートしているので、なおさらそう思う。
    スタイルシート管理の問題はあるし、Remix/React Router のようにルート単位で CSS ファイルを定義して適用する方法は気に入っている。それで足りない場合や、動的スタイルが .css ファイルでは複雑になりすぎる場合は、style={{...}} もいつでも使える。
    CSS は強力で柔軟で拡張可能なので、Tailwind は改善というより制限のように感じる。なぜ人気が続いているのかはよく分からないが、3〜4年後にはみんなまた別のものへ移っていると思う。

    • 最初は CSS を学び直すようで歯がゆく、以前は同じ主張をしていた。
      だが Tailwind を使っているオープンソースプロジェクトに貢献するうちに慣れて、今は違う感じ方をしている。
      Tailwind は本質的には style={{…}} の短縮記法に近い。.css ファイルやスタイルオブジェクトなら複数行必要なものが、1つのユーティリティなら15文字程度で済む。
      「visual text replacement css」のようなものを検索したり、CSS チートシートや8年前の CSS-Tricks 記事を漁ったりする時間が大幅に減った。代わりに常に Tailwind のドキュメントを見て、やりたいことを実現するユーティリティクラスを素早く見つけている。
      驚くほど多くの部分が頭の中のキャッシュに入り、レイアウト作業に必要な CSS をすべて覚えようとするよりずっと良いと感じる。
    • 今ではコンポーネント全体が1つのファイルの中に収まるからだと思う。
      別途 CSS を触る必要がなく、スタイルが適用される要素のすぐ上にあるので、照らし合わせる必要がない。
      css 属性だけでも可能ではあるが、みんなそれは間違ったやり方だと教わってきたという問題があり、複数のユーティリティが入った文字列のリストのほうが、純粋な CSS オブジェクトを使うより簡単でもある。
    • 制限は可能な複雑さを減らす。だから Tailwind が勝つ。
      巨大で複雑なシステムの上に載った、組み合わせ可能で標準化されたモジュール型ラッパーなので、大きな前進だ。
    • 子どもと数学を学んでいるが、自分が習ったものと違うわけではなく、今でも素早く解ける。
      一方でソーシャルメディアには、掛け算と割り算をごちゃ混ぜにして正解は1つだけだと言う投稿がある。Tailwind がそこまで悪いわけではないが、年を取った立場から見ると、その方向に近く見える。

  • Tailwind は好きだ。この4年間で3つのプロジェクトで使い、直感的で、ドキュメントが良く、シンプルだった。
    プロジェクト内のスタイル付き div すべてに名前を付けなければならなかった emotion や styled-components の時代が懐かしいとは思わない。
    Tailwind ではコンテナはただの div といくつかのクラスにすぎない。命名論争が減り、名前を考えるために使う頭とレビュー時間も減る。

    • styled div ごとに名前を考えなければならないという問題をよく見るが、少し不思議に思う。
      何かに名前を付けるのに1秒以上考えたことはほとんどない。実際に誰かにとっては、そこが詰まるポイントなのだろうか。本当にそこで麻痺するほどなのか気になる。
    • 「いくつかのクラス」と言うなら、かなり優秀なプロダクト責任者と働いているようだ。
      私が経験した人たちは、考え得るあらゆる細部を際限なく指定しがちだった。Web フォームを自分専用の HGTV リノベーションのように扱う。
      Tailwind を一度使ってみたとき、クラスの数はマークアップより一桁多くなり、すぐに読みにくくなった。
    • 複数のプロジェクトで使ってみたが、好きにはなれなかった。大きなプロジェクトではすぐに散らかり、新しい Bootstrapのように感じる。
      今は CSS-in-JS のワークフローに満足している。LLM の助けを借りて昔ながらの CSS を書く方法だ。LLM に画像を見せてコンポーネントを依頼すると、適切な名前まで付いた状態ですぐに出てくる。
    • 選べるなら React を避ける主な理由の1つがこれだ。
      React でのスタイリングはいまひとつで、Tailwind を使っても、せいぜい比較的ましな選択肢にすぎない。
      フロントエンドフレームワークとビルドステップを使うなら、用途によっては Svelte と Astro が良い。普通の CSS でスタイリングでき、コンポーネントを小さく保てばクラス名をほとんど使わずに済む。
      要素セレクタを使い、フレームワークにビルド時点でスタイルのスコープを切らせればよい。

  • 自分のサイトで Tailwind を使ってみて、かなり気に入った。ただし、よく言われる理由とは少し違うかもしれない。
    Tailwind の本当の価値は、1つの要素に影響するすべてのスタイルを1か所で読めることだ。
    クラス名は長くなることもあるが、毎回ブラウザの開発者ツールを開いたり、1つ以上のスタイルシートを上下に行き来したりするより、長い1行を読むほうがずっと速い。
    後でそのコードに戻ってきても、別の要素を変えてしまうのではないかと心配せず、自信を持って修正できる。
    CSS のカスケードする性質は今でも有用だが、通常はスタイルを1つの要素だけに限定したい。残りは CSS に戻るが、実際に書く CSS はごく少ない。たいていは余白を整えたいだけだからだ。

    • まさにそこが Tailwind の良くて便利な理由だと思う。
      「X はどうやるのか？」が30分の調査作業ではなく、素早いドキュメント検索で済む点も気に入っている。
    • 要素に適用されたすべてのスタイルを表示するツールは IDE にもある。たとえば IntelliJ の「Show Applied Styles for Tag」や Chrome 開発者ツールでも読みやすく表示してくれる。
      この HN の投稿に出てくる Tailwind の断片は、それに比べるとかなり怖く見える。
    • ある程度は同意するが、同じ問題は残っている。
      div に text-xl を追加し、その中にネストした div と span があると、すべて text-xl を継承するため、ネストされた要素では何が text-xl を引き起こしているのかを見るには、結局要素階層をさかのぼる必要がある。
      それでも全体としては少し簡単ではある。

  • 「ビルド時間の短縮」「もう @tailwind ディレクティブは不要」「JavaScript 設定なし」「モダンな Web のために設計」という文句は、こう聞こえる
    CSS は今や私たちが手作業でやっていたことを全部できるようになったけれど、それでも私たちはまだ自分たちが必要だと装い続けよう、という感じ

    • 嫌うなら、せめてそれが何で、なぜ人々が使うのかを理解しようとはするべき
    • Tailwind のセールスポイントは最初から「ほぼインライン CSS だが、style 属性より面倒が少なく、ずっと最適化しやすい」だった
    • 以前は通常の CSS ではできなくて Tailwind が必要だったものが何なのか気になる
      Tailwind はほとんど CSS と 1:1 で対応しているのでは？
    • 本当にそう受け取ったのかと思う
      Tailwind が好きでないのは理解できるが、藁人形論法で攻撃するより、Tailwind のどこが嫌なのかを言うほうがいいと思う
      他人のオープンソースプロジェクトや、それを有用に使っている人たちを貶めるのもよくない

  • CSS に詳しい人たちに聞きたい。私は詳しくない
    個人の Phoenix プロジェクトを 1.7 に上げているところで、Phoenix が今はデフォルトで Tailwind を使うようになったので、Bootstrap の代わりに試してみようと思った
    これまでは Bootstrap 版は「まあまあ悪くない」見た目だったのに、Tailwind 版はめちゃくちゃに見える
    デザイナーになろうとしなくても、そこそこ見栄えのするデフォルトを得るいちばん簡単な方法は何だろう？ それとも単に Bootstrap を入れ直して終わりにすべきだろうか？

    • その場合なら Bootstrap を入れ直すほうだと思う
      Tailwind はデザインを制御したいときに道具をくれるが、結局はデザインを自分で制御しなければならない
      ただ見栄えがよくて Bootstrap っぽいもので構わないなら、Bootstrap が正解
      理論上は Tailwind の上に Bootstrap を再実装したプロジェクトがあり、Bootstrap のような出発点と Tailwind の力を同時に与えてくれるはずだが、実際には単に Bootstrap を使うよりうまく機能するものを見たことがない
    • その目的には DaisyUI を使っている。サンプルのデモサイトはこちら: https://nwk-landing-kit.netlify.app
      DaisyUI のドキュメントはこちら: https://daisyui.com
    • Bootstrap のようなコンポーネントを探しているなら、無料で https://flowbite.com/ を試す価値がある
      Tailwind にも有料コンポーネントがあり、ただコピー＆ペーストすればよい。慣れてくると Flowbite のコンポーネントを少しずつ直せる点がいい
    • 誰が金を払うかによる
      雇用の安定があり、あれこれ触ってみたいなら Tailwind で遊んでもいい。流行に敏感で声の大きい人たちは、だいたい Tailwind が好きなようだ
      だが自分のプロジェクトだったり、自己資金だったり、締め切りがあるなら、すでに知っている Bootstrap を使って、UI で消耗戦をするより仕事を終わらせることに集中するほうがいい
    • Tailwind と Bootstrap は、リンゴとアップルパイを比べるようなものに近い
      Tailwind はコンポーネントを作るために積み上げるクラス群を提供する
      UI コンポーネントのソースを一緒に使えばもっと簡単になるはず。以前 TailwindUI を使ったことがあるが有料だったし、良い無料の代替もあると思う

  • 「Tailwind か否か」の会話には明確なパターンがある。Tailwind が言及されるたびに繰り返される
    30分以上まともに使ったことがなく、少し試しただけかドキュメントをざっと見ただけの人たちがいる。彼らは Tailwind を嫌い、「素の CSS」のようなものを好む
    一方で、実際のプロジェクトで、1人より多いチームの中で使ったことがある人たちがいる。彼らは価値を理解し、トレードオフを受け入れ、好んでいる
    最初のグループから2番目のグループへ移る人は多く見てきたが、2番目から最初へ戻る人はほとんど見たことがない
    だから Tailwind は成功したのだ。純粋主義者の目には美しくないかもしれないが、作る人や実用主義者の目には本当に素晴らしい

    • 私はその2つのグループのどちらにもあまり当てはまらないと思う
      Tailwind に反対しているわけではないが、まだ使っていない理由は、Web Components や React Styled Components のような他の選択肢より、なぜ優れたアプローチなのかがよく見えないからだ
      最大の問題は、Tailwind が HTML を大量のユーティリティクラスでごちゃごちゃにし、読みにくく保守しにくくする点だ
      巨大なグローバル CSS ファイルや、古典的なタグ名ベースの CSS より良いことは分かるが、コンポーネントにスコープされた CSS をグローバル名前空間を汚染せずに使う方法はすでにある。Web Components と Styled Components がその例だ
      どちらもスタイルをコンポーネント、より一般には特定の HTML タグのまとまりに直接結び付けるので、どのスタイルがどこに適用されるのかが分かりやすい
      グローバルなクラス名も不要で、望まない副作用や衝突を心配することも減る。コンポーネントを削除すれば関連するスタイルも一緒に削除されるため、使われていない CSS が残る心配もない。shadow DOM のおかげで、あるコンポーネントのスタイルが別のコンポーネントに意図せず影響するリスクもない
      表現用のスタイルをマークアップに直接混ぜず、HTML を短く読みやすく保つことを重視している。Tailwind のようにスタイルがすべて class 属性に入ると、1行に長いクラス一覧ができ、実際のクラス名まで一緒に書かなければならない場合は HTML が雑然とする
      どのスタイルが適用されるのか一目で把握しにくく、適切にインデントするのも難しい。かつて HTML のインライン style 属性から離れたさまざまな理由を思い出させる
      Tailwind を嫌っているわけではないが、読みやすさ、保守性、関心の分離という面で、Web Components や Styled Components より明確な利点が見えず、まだ答えの出ていない懸念が大きい
      ドキュメントは読んだが使ったことはなく、なぜ他の選択肢ではなく Tailwind を選ぶのか理解しにくい。普通の HTML の真ん中でクラスが非常に多くなる点は、私にとってはどちらも読みにくくしてしまう

  • Tailwindを便利に使い、生産的に働いている人たちがいることは認めるが、今ではTailwindがどこにでもあるので、すっきりしているがありふれた見た目をあちこちで見かける

    • これはTailwindとTailwindUI/shadcnなどを混同している
      概してTailwindは、通常のCSSよりもスタイルに大きな影響を与えるわけではない。例外は少しある。影のようなものはやや標準化されており、indigoのカラーパレットが最近外部にも影響を与えた程度だ
    • Tailwindは合理的なデフォルト値を提供するが、デザインに大きな影響を与えるわけではない
      人々が特定のやり方でサイトをデザインする傾向があるだけだ。特にShadCnと一緒に使う場合はそうだ
    • むしろ良いことのように感じる。Tailwindの選択肢はよく設計されていて、うまく機能する
      WebサイトのフォントとしてInterが新しいHelveticaのように使われているのと似ていると思う。多くの人が使っていて見栄えが良いなら、あえて使わない理由があるのかと思う
    • 以前もBootstrapについてこういう話を聞いたが、自分が作ったBootstrapサイト同士は似ていなかった
      BootstrapはTailwindよりずっと前から多くのユーティリティクラスを提供していて、かなりの時間を節約してくれたし、特定の見た目を強制しなかった
      必要なクラスだけ読み込めばよかった。もちろんSassのソースファイルをダウンロードしていなかったなら話は別だが、それは愚かな選択だっただろう
    • この問題についての自分の考えは、良いUIフレームワーク、つまりTailwindとコンポーネントの組み合わせがまだ少ないということだ
      そのため大多数のプロジェクトが、ごく少数のフレームワークを使っている。質の高いUIプロジェクトがあと4〜5個出てきて、特にスタイルの方向性がもっと異なれば、多様性は増えるだろう
      デザインも多くの創作活動と同じように、驚くほど少数の人々が流れを決めているように思える
      もっと多くの人にこのことを知ってほしい。才能ある人たちが「自分が作っても誰も耳を傾けないだろう」と思って作らないケースがある気がする
      しかし、そうした人たちの一部が挑戦すれば、Webの大きな部分に新しいUIを開くことができると思う

  • Tailwindはインラインスタイルの利点、つまり名前を付けずに何かをスタイリングする方法と、文字列の普遍性、そして文字列の限界を示す証拠だ
    その次に来るものが楽しみで、それまでは渋々Tailwindを使うつもりだ