Tailwind考 - uhyo/blog

皆さんこんにちは。最近とある事情でTailwind CSSにわりと真剣に向き合わないといけなくなった筆者です。 Tailwind CSSの話題は、Twitterのフロントエンド界隈では定番のトークテーマのひとつです。しかし、筆者の考えを文章にまとめたことは無かったので、このたびブログ記事にすることにしました。 結論筆者が一番みなさんに伝えたいことは、Tailwind CSSは考え無しに採用してよい技術ではなく、採用するには熟慮が必要だということです。とくに、フロントエンドのスターターキット的なプロジェクトの中にTailwind CSSが混ざっていることがありますが、あれはけっこうな罠です。気軽に採用すべきものではありません。 筆者の考えでは、Tailwind CSSの採用を考慮に入れてよいのは次の2つの場合です。 デザインにこだわりがなく、最低限整っていればいい場合。デザイナー不在のプロジ

[Phenomenon]

命名について異論があり、コンポーネントの分割の単位はプロジェクトの方針によるしwrapper、outer-wrapperみたいな名前も正直なところ1秒も考えたくないんですよね…。ほかはとても参考になりましたが。

[tokuniimihanai]

非常に真っ当な考察。このレベルのことを理解せず筋違いの批判をしたり、過度に持ち上げる人が多い印象。ただクラス名の粒度はコンポネの粒度よりは大抵細かいので、流石に命名の負担は減るのでは？とは思った。

[ducktoon]

内心あとのことはどうでもいいプロジェクトに使ってる

[circled]

css書ける人が一度tailwindcss使ってしまうと、恐らく二度と昔の書き方をしなくなるのがtailwindcssだと思っている

[knjname]

使い慣れた上で80点ぐらいの品質のものを高速に出したい、zen codingみたいな立ち位置があると思ってる

[yahsan2]

共感だった。 Tailwind 好きなので、命名に関する補足視点をかいてみた。 命名を先送りできる嬉しさ https://zenn.dev/yahsan2/articles/c899978c83243c

[takyam1213]

reactでcssどうするか問題に悩まなくていいためのやつだと思ってる

[easy-breezy]

Tailwind、ルールを定めずに個々のエンジニアがそれぞれ0からマークアップして実装したプロジェクトは地獄だった

[kvx]

クラスだけでメディアクエリが扱えて、.innerとか.outerとか.inner-innerとかのwrapperクラス名に悩まなくてよくなるだけで正義。

[shingo-sasaki-0529]

いやぁすごい。 Tailwind に対するモヤモヤを一気に晴らす言語化能力を感じる。技術の良し悪しに向き合うときにはこうやって考えを形にするんだって見本になってる。

[yarumato]

“見た目ではなく内容を表すCSSクラス名は命名の苦しみがあるが、結局は適切にReactコンポーネント（を命名して）分割するので、Tailwindを使っても命名する必要からは逃れられない”

[Rishatang]

TailwindのJiTを見た時「いやいやこれTailwindの良さ潰れるだろ…」って思ってたけど、同じこと書いててくれて嬉しい。ある程度小さいコンポーネントなら命名しんどいと思ったこと無いって点も同じ

[koogawa]

“デザインにこだわりがなく、最低限整っていればいい場合” “逆に、デザインシステムをしっかりと整備しそれからの逸脱を防ぎたい場合。”

[ninjinkun]

まさにこの中にあるようにデザインシステムによる制約を自由度とのバランスをとりつつ強いる目的でTailwindを使っていたので、自分の使い方が合っていたようで安心した

[rryu]

ユーティリティベースのCSSの欠点はHTMLからは同じコンポーネントかどうかが判別しづらいのでドキュメント化しておかないと無尽蔵にコンポーネントが作られてしまうところにあると思う。

[bleu-bleut]

Tailwindのコアとなる機能は「CSSフレームワークを生成する」こと

[kijtra]

普段から使ってる人から見ると一部の批判が「ちゃんと使ったことないな」とわかるやつだよね。

[nzxx]

“Tailwindは複合的なソリューションです。”の部分はまさにこれが皆の感覚と一致したから採用されていってるんじゃないかなと思っている

[hylom]

公式サイトには良さげなコンポーネントが並んでいますがそれらは標準では提供されていないという罠、それはそれとしてReactと組み合わせて使うには便利（コンポーネントごとのCSSを別途用意しなくても良いあたりとか）

[mayumayu_nimolove]

tailwindはザックリ素早くできる。緊急時のサイトとか向いてる。細かいデザインもCSSなんだから上書きできるよ。flexやgridやレスポンシブなどレイアウトタグしか使わないという手もある。使い勝手最強でしょ。

[riawiththesam]

1の労力を解決するために1のコスト使ってる感じがして将来性が高いと感じれないんだよなー 難しい

[baronhorse]

あのユーティリティクラスのごちゃごちゃを書きたくないという気持ちが伝わってくる

[ohesotori]

数人しか見ない管理画面とか作るの、これでいいんちゃうって思ってたわ

[mon_sat]

Tailwind CSS の認識に違いはないのだけど、結論としては差がある。風に身を委ねて流れるままに活用している。導入にマイナスがないしベストプラクティスも構築されやすい。まあ本家使用ではなく UnoCSS か Windi CSSだけど

[onesplat]

シンプルに要らんと思ってる / 言いたいこと大体ここに書いてあった https://coliss.com/articles/build-websites/operation/css/why-tailwind-css-is-not-for-me.html

[prograti]

横展開しやすいので個人的には凄く気に入っていますね。書かれている内容ももっともだと思いますが、従事するシステムによって意見は分かれそうな気もします。

[youkan94]

すごくいい記事だと思いました。Tailwindという制約の話の対比として、CSSの自由があると思うのですが、その場合のメリデメ（複雑さ、保守性、デザインシステム構築、可読性なども）も考えていく必要はあると思いました

[manimoto]

秩序あるBEMやFLOCSSを構築し保ち続けるのは労力が凄まじいので、それらの構築保守から解放されコンポーネントに集中できるようになったのは多大な利点だと思ってる。また使うなら独自定義も任意の値は使うべきでない。

[kojika17]

"デザインシステムを強制するという観点からは、Tailwindの手法は筋がいい" 同意

[masa_iwasaki]

同意。 “デザインにこだわりがなく、最低限整っていればいい場合”にコンポーネントベースに開発しているならUIツールキットのほうが手早い印象だけどそっちはツールキットの方針を見極める手間もあるので悩ましい。

[Cherenkov]

tailwindのクラスをdev tools上から付けても反映されなかったからモヤモヤした

[waicode]

デザインシステムの導入に本質的に等しいは、なるほどたしかに。コンポーネント分割したあとBEM入れてグローバルなCSS設計を気をつけた方が、大半のケースで組織を選ばず保守性が上がりそうではある。