逸脱事例を含めてすべてをレールに乗せる
ライブラリやフレームワークの価値として、一定の制約を設けて典型事例をそのレールに乗せるというのがあると思う。それは書き方のルールであったり、あるいは受け取る値を型で制限することだったりする。
一方、現実のソフトウェアではたとえそういうフレームワークを使っていたとしても、時に逸脱する実装を取らなければいけないことがある。その時、フレームワークはその逸脱事例を 公式の方法として 書けるようにすべきかという問題が生じる。
たとえば最近 Tailwind.css は @tailwindcss/jit で、任意の値をクラス内に書ける記法をサポートしつつある。
code:html
これに対して「いやそれはインラインスタイルを使うか別途 .css を設けたほうが良いじゃないか」という感想が湧くかもしれない（実際、これがない頃はそうするしかなかったのだ）。
確かに、Tailwind のルールから逸脱する箇所はそこだけ Tailwind を使わないほうが素直じゃないか、という考えには一定の道理がある。一方で私はこの機能を歓迎する。なぜだろう？
重要なのは、こういう機能を入れる（あるいは良いと感じる）のは必ずしも「 #CSS を生で書くのが苦痛だから」ではないということだ。もし上の機能を称賛する理由がそこである場合、その考えは間違っていると思う。CSS を書けた上でなおこういう機能を良いと思うのはなぜか、という話をしたい。 まぁこの機能に関して言えば「インラインスタイルでは @media クエリが書けないから」という面が大きいのだけど、結果 .css を別途作らなくなることで 技術の混在がなくなる というのが大事なポイントなんだと思う。
せっかく Tailwind.css を導入してるのに、コンポーネントによってここは .css だったり .scss だったり Tailwind のクラスだったりする、という敗北感がなくなる。
ライブラリは複雑になるかもしれないが「基本的にすべてのコンポーネントは Tailwind で書けば良い」という状況になることでプロジェクトのルールはシンプルになる。これが上の機能が良いと感じる理由だ。
プロジェクト内に技術の混在がなくなることはそれ自体に価値がある。しかしそれを実現するための複雑さはフレームワークやツールに押し付けたい。 #デザインシステム のような、一定のレールを敷くために導入したはずの Tailwind に逸脱事例のサポートまで要求するのは変な気もするが、それはそういうものだと思う。Tailwind に限らず「強い」ツールは逸脱事例を含めてすべてを同じレールに乗せる側面を持っている。 ------
話は大きく変わるが、たとえば #Rails の self.table_name = はどうだろう。これに対しても @tailwindcss/jit と同じ感想を抱くだろうか。「ActiveRecord の規約に沿わないテーブルを扱うクラスはそこだけ生 SQL で書くほうが素直で良い」……と思うだろうか（そういうこともあるかもしれない）。 仮にあなたを含めたチームメンバー全員が生 SQL を書くことに苦痛がなかったとしても、混在することそのものが悪なので ActiveRecord 公式の方法として書けたほうが良いという考えはありうる。そして多分、だからこそ ActiveRecord はそういう機能をサポートしてるんだと思う。でもまぁ、そう考えない人も確かにいそうな気はする。
混在することそのものが悪になるケースを防ぐため、レールを提供するはずのフレームワークが無限の拡張性や力強い設定ファイルを持つことがある。それは決して規約の統一に失敗したとか「敗北した」といったものではなく、むしろこれができることが「強い」ツールの条件ではないかと感じている。究極的にはすべてを覆い尽くす力をレールの先（あるいは手前？）に持っていて欲しい。
昔から CoC（設定より規約）という考え方があるけど、それでいうと私は「結局両方できるやつが最強というか、デフォルトのレールがあった上で設定も最強にできた方が良いに決まってるだろ」という身も蓋もない考えを持ってることになる。
そういう身も蓋もないツールを見ると嬉しくなってしまう、というのが tailwindcss/jit に対する感想の正体なんだろう。
成功した #フロントエンド のツールにはこういう特徴があるというか、Webpack に対する感情もこれに似てて、一方 Rails の Webpacker には前者しかない（デフォルトを提供することが唯一の価値になってるせいで「弱い」ツールになっている）点が嫌いなポイントだったのだなと言語化できた。素の Webpack にはちゃんと両方ある。 #TypeScript が他の AltJS より強かったのもやっぱりこう「身も蓋もなかった」おかげというか、もし TypeScript が「こういう条件のファイルは .ts にできないのでそこは .js のまま運用してね」みたいなことを言うやつだったら（今でも言い続けるやつだったら）ここまで広がらなかっただろう。 「そんな使い方じゃ TypeScript の恩恵ないじゃん」ってケースまで何故か .ts で書けることには見た目以上の価値があったのだと思う。これも「すべてを覆い尽くす力」の例。