Tailwind CSS
2022-09-05
-
TailWind CSSはPost CSSのPlugin
-
PostCSS
-
要約
- jsで書いたプラグインでCSSを変換し、結果を純粋なCSSとして出力するツール
- 早い
- 独自のCSS拡張みたいな感じ？
-
ベンダープレフィックス等のプレフィックスをよしなに付けてくれる
AutoPrefixerは便利そう - SCSS(AltCSS)は同じ様な概念だが、SCSSはCSSの拡張コーディングの仕組み（？）
-
PostCSSが出来た背景
-
SassやLessなどの独自構文を使用せずに、W3Cで策定中の次世代CSS構文でCSSの実装を統一したい
- AltJsからbabelのコンパイラに移行したのと似ている
-
SassやLessなどの独自構文を使用せずに、W3Cで策定中の次世代CSS構文でCSSの実装を統一したい
-
PostCSSのアーキテクチャ
-
- 入力CSS：開発者が実装したCSS。AltCSSでもPureなCSSでも可能です。
- Parser：入力CSSを解析し抽象構文記（AST）を構築する。
- Plugin：Parserで生成したASTに対してプラグインでCSSの処理を実行する。
- Stringifier：プラグインで変更されたASTをトランスパイルしてCSSを出力する。
- プラグインを使用しない場合、入力のCSSがそのまま出力のCSSとなる
-
プラグインの扱いに注意
- プラグインの実行順によってはエラーが発生する
- プラグインの選定コスト（メンテされてないものなど）が高い
-
-
感想
- AltCSSの学習コストがいらないとのことだけど、結局独自の構文を覚えないといけない
- 結局変換のパイプライン問題があるので、手を出すのは余計なコストが掛かってしまう気がする
-
要約
-
PostCSS
-
TailWind CSSとは
-
要約
- BEMなどのCSS設計アプローチと異なる
-
Utility Classと呼ぶp-6``max-w-smなどのプリミティブ(プロパティとほぼ対応する）クラスをあてがう -
CSSそのものを角換わりに、
utility classをclass属性に追加していく開発スタイル
-
メリット
-
class名の発明をする必要がない- 単なるflex-containerに名前を付ける必要はない
- ネーミングルールの設計、遵守の必要がない（そもそもネーミング作業がなくなる）
- CSSを完全に再利用するので、CSSのサイズ肥大化防止
-
スタイルの変更をHTMLローカルで行える
-
CSSはグローバル変数、HTMLの class はローカル -
CSSの変更で他ファイルのスタイルが壊れる心配をしなくて良い
- CSSを変更する場合はconfigファイル
- スタイルの変更はタグに付けたclass名の変更なので、影響範囲はそこにとどまる
-
-
-
デメリット
-
インラインスタイルっぽい
-
インラインスタイルは
media queryや擬似クラスが使えないので、utility classのほうが上回る
-
インラインスタイルは
-
メンテナンス性が悪そう
-
確かに毎回utility classを当てはめていると本当にメンテナンス性が悪い
-
<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-green-500 hover:bg-green-700">Click me</button>
-
-
使い回す場合は、
templateやjs componentをつくる- ReactやVueなどの使用が前提
-
確かに毎回utility classを当てはめていると本当にメンテナンス性が悪い
-
utility classとcssの対応を扱うのが大変そう
- それはそう
- VS Code Extensionを使え
-
インラインスタイルっぽい
-
感想
- 思想は確かに共感できた
-
使い回しにコンポーネントを作れというのは結局カスタムクラスと同じなのでは？
- ネーミングコストがかかるので
- いや、ネーミングコストは最上部の部品だけで、中身はプリミティブだからそれは違う
-
汚いHTMLを推進している
- Utility classの記述によってHTMLがごちゃごちゃに見える
-
将来的に乗り換えるときのコストがヤバそう
- 他のフレームワークやツールと互換性がない
-
要約
- 参考
- tailwindcss のコンセプトとメリットについての考察
- Tailwind CSSが私には合わなかった理由
月別アーカイブ