TailwindCSSという言語

私は、TailwindCSSは言語だと思っています。

class属性の中にプログラムできる言語です。

デフォルトで用意されているものだけでもかなり有用ですが、頻出するパターンに合わせて専用の言語にカスタマイズすることができます。

それだけでもかなりワクワクするのは、私だけなのでしょうか？

人間工学的

私がTailwindCSSが人間工学的だと思う理由は、マークアップ内に記載していくスタイルが標準的¹であるからです。

なぜそれが人間工学的かといえば、エディタ内での移動を最小限に抑えることができるからです。

import文を書いたり、クラス名を付けてCSSを書いたり、新しいコンポーネントファイルを作る手間はなるべく避けたいのです。CSS-in-JS のために変数を定義して、それを参照するために変数の中を確認するのすら億劫なのです。

もちろんコンポーネント化を捨てたわけではありませんが、その目的の多くが「ほんの少しのTailwindCSSコード」で代替できてしまうのです。

私と同じ"怠惰なプログラマ"はTailwindCSSをきっと気に入るはずです。

ちょうどよく頭を使える

例えば「丸角でパディングが入った、背景がプライマリカラーで文字が白のボタン」が必要になったとします。

TailwindCSSなら、HTML標準のbutton要素と組わせて、「」内の説明をありのままに表現するだけです。

<button class="rounded p-4 bg-primary-500 color-white">click me</button>

TailwindCSSを使わずに、Buttonコンポーネントを作り、属性を用意し、color属性に 'primary' | 'secondary' を設定できるようにしたりすることが多いかもしれません。

その結果、全く違うデザインのボタンが出現して、違う名前でコンポーネントを作った結果ロジックが分散したり、バリエーションに対応するために属性を増やして、組み合わせで制御しようとしてコンポーネントの実装が複雑になっていくのです。

TailwindCSSにはCSSと同程度に汎用的な部品であるユーティリティが用意されています。

属性の組み合わせを考えなくても、ユーティリティの組み合わせで十分表現できます。

「丸角でパディングが入った、背景がプライマリカラーで文字が白のボタン」

これに命名せずとも、文章をそのままに表現することで同じ目的が達成されます。

Buttonコンポーネントを使う側は、使える属性を調べる必要がありますが、TailwindCSSではすでに用意されている「言語」から慣れ親しんだ用語を使って、今カーソルを置いているその場所でコーディングを終わらせればいいのです。

「ユーティリティを組み合わせる活動」は、私にとって「ちょうどよく頭を使う活動」で、その点がとてもうれしいのです。

（※ ちょうどよくない！難しい！ユーティリティを覚えるのが大変だ！と感じるなら、それはCSSそのものへの不理解が原因ですので、CSSの勉強を頑張ってください。）

「デザイン」という活動との親和性

よくあるコンポーネント活用の謳い文句はこうです。

「一度UI部品を作ってしまえば、それを使いまわして、迅速にUIを構築できる」

しかし、多くのデザイナーは「好きに作れ」と言われて、UI部品なんていう考え方はしないでしゅお。

効果的に見せるために、細部を変えるかもしれません。（神は細部に宿りますから）

プログラマは文句を言って、「この二つのボタンのデザインを合わせてくれ」とかあるいは「Atomic Designを導入しよう」と言い出すかもしれません。

優しいデザイナーはそれに応えて、「同じもの」としてボタンを２つ作るでしょう。

プログラマはそれを見てまた文句を言うでしょう。

「この２つは、今のコンポーネントの実装を大きく変える必要がある！」

このようなやり取りの末に、"実装に合わせてデザインを行う"というような本末転倒な状況に陥ることのをよく見たことがあります。（開発目線でのフィードバックや交渉を否定しているわけではありません）

そうしてできたデザインや要件定義は、どこか人間的でなく使い勝手の悪いものになります。

過度に機械的プロセスを求めるあまり、デザイナーの思考プロセスまでもが機械的になってしまうからです。

（もちろん入力項目欄が１００も２００もあるような場合は話は別かもしれませんが、そうなっている時点で使い物にならないことに気づくべきでしょう）

デザインという人間の芸術的な活動を柔軟に受け入れるには、汎用的な部品をデザインに合わせて組み合わせるという「ちょっとした生産的活動（つまり、プログラミング）」を拒まないプログラマとしてのメンタルモデルが必要になります。

ReactやVueの提供する「コンポーネント機能」に「UI部品」としての役割を過度に求めていては、そういったメンタルモデルとは逆の方角へ進んで行ってしまいます。

一方のTailwindCSSは、そういった心構えを無理なく心に宿してくれます。

そういう面で私はTailwindCSSが好きなのです。

終わりに

あるポエムを読んで、TailwindCSSに関してフロントエンドプログラマたちが日夜激論を繰り広げているというようなことを知りました。

これだけTailwindCSS愛を書いておきながら私は、「そんなことどうでもよくないか？」とか思ったりしていたことは内緒です。

そして参戦はしたくないが、他人が書いたTailwindCSSに関する素晴らしい記事（批判する記事でも、肯定する記事でも多くのことが学べる記事ばかり）を見て、私も何か書いてみたいという気持ちになり、結果何の学びもなさそうな記事を生み出すに至った次第です。

私自身は、TailwindCSSにはまだまだ問題が多く残っていると思っています。

主に、PurgeCSSという「妥協案」とShadow DOM内での利用に関するものです。

この２つは、もしかするとTailwindCSSを言語として捉える見方を突き詰めれば解決するのではないかとも思っています。

例えば、class属性ではなく専用のdata-tw属性に書くようにして、言語としてパースすることでどうにか解決に向かうのではないかと思っているのです。（だったら自分でやりなさい、というご指摘はその通りでございます）

ベーススタイルも、tw-buttonというカスタムコンポーネントを作っておいて、ボタンのCSSリセットのみ当てておけばいいような気がしているのですが、今のTailwindCSSでそれができるかはちょっと悩ましいのです。（CSSをパースすればたぶんできる）

そんなこんなことを考えつつも、仕事ではふつうにSassを使っている不届きものがお送りしました。

ここまでご精読いただき、まことにありがとうございます。

もし興味を持ったら、ぜひTailwindCSSを導入し、カスタマイズすることで自分やプロジェクトだけのものにしてもらえたら嬉しい限りでございます。

@apply ディレクティブを使ってCSS内でクラスを作ることはできます ↩