Closed sora-ichigo closed 1 year ago
css ライブラリどれ使うのがいいんだろう
bootstrap とか semantic ui は tailwindCSS と何が違う?
クラスの命名規則が違う
.pt-4
.btn
, .link
逆に何が一緒なんだろう
この問題は、詰まるところHTMLとCSSが別ファイルになっていることが根本的な原因です
セマンティックファーストは命名がむずすぎる問題がある?
命名が難しい → スコープが大きいから?
↑ BEMについて
css ファイルの中だけでスタイルを構造化(分割)しなければならなかったため生まれた設計規則?
今時の css は JS ランタイムにうまく乗っかることでその問題をよりシンプルに解決している?
react だったら component の単位で css もくぎれるようになった?
↑ これはでも CSS in JS だけの話かもしれない
css modules は css ファイル単位でスコープを区切ることに成功している
TailwindCSS 使うなら必須かも https://github.com/FullHuman/purgecss
使っていないクラスのcss定義をビルド時に削ってくれる
https://tailwindui.com/components
Tailswind CSS で作った React Component 集
TailwindCSS っていつ使うべきなんだろう
https://github.com/youngeek-0410/dev/issues/10#issuecomment-1335105790
react だったら component の単位で css もくぎれるようになった?
CSS in JS のメリット
筆者が一番みなさんに伝えたいことは、Tailwind CSSは考え無しに採用してよい技術ではなく、採用するには熟慮が必要だということです
筆者の考えでは、Tailwind CSSの採用を考慮に入れてよいのは次の2つの場合です。
デザインにこだわりがなく、最低限整っていればいい場合。デザイナー不在のプロジェクトなど、デザイン上の細かな要求が無いがとりあえず整えておきたいという場合は採用してもよいかもしれません。Bootstrap的な立ち位置のものが欲しい場合です。
逆に、デザインシステムをしっかりと整備しそれからの逸脱を防ぎたい場合。ただデザインがあるだけでなく、フロントエンドエンジニアまで巻き込んでデザインシステムを整備したいということが重要です。このようなユースケースではTailwind CSSのアプローチが適している可能性があります。
「何を使って CSS を書くか」という戦術よりも「どうやって影響範囲を特定し・継続的にリファクタ可能な体制を作るか」という戦略の方が、よっぽど重要なこと
https://zenn.dev/takepepe/articles/frontend-testing-motivation
ユーティリティーファーストな CSS フレームワーク
uhyo先生より 一言で言えば、Tailwind CSSはメタCSSフレームワーク、あるいはCSSフレークワークジェネレータです
アプリケーション内に自分で css を書かないのが特徴(?)
https://blog.uhy.ooo/entry/2022-10-01/tailwind/ では bootstrap 的な使い方も想定されているが、それなら css を直接書くか、bootstrap 的なものを使う使うかすれば良いじゃない?という考え
JS ファイルの中に CSS を定義する。 https://styled-components.com ならこんな書き味。
const Button = styled.a`
/* This renders the buttons above... Edit me! */
display: inline-block;
/* ... */
/* The GitHub button is a primary button
* edit this to target it specifically! */
${props => props.primary && css`
background: white;
color: black;
`}
`
const Component = () => <Button />;
https://styled-components.com/docs/basics#motivation
React のような宣言的なUIライブラリで、パッとCSSを書きたい時? 開発者体験がとても良く、素のCSS構文を内部で利用するので今までのコードを使いまわせたり他のCSS ライブラリへの移行がそこまで難しくないと思われるため。
反対にパフォーマンス面に懸念があるため、パフォーマンスに要点を置いたサイトでは利用しない方がいいかもしれない。またいくらでも自由に CSS を記述できてしまうのでデザインシステムとしての利用は厳しいのかも?
JSのモジュールシステムによってCSSにスコープを持ち込むしくみ
CSS in JS ながら、ビルド時にはCSSファイルが生成される 書き味はほとんど Styled-Components
const Card = styled.a<{ imageUrl: string }>`
display: block;
width: 200px;
height: 140px;
background-repeat: no-repeat;
background-size: contain;
background-image: ${(props) => `url('${props.imageUrl}')`};
`;
古き良きスタイル定義。ページロード時に全て読み込み、スコープという概念が存在しない。そのため BEM のようなCSS設計規則を持ち出して上手にスタイル定義を構造化する必要があった。
バグを生みやすく、開発者体験も良くなかった。上であげられているような CSS ライブラリが出てくるまでは pure な CSS を頑張るしかなかったが、現在はその必要がないためほとんど利用を見かけない
https://github.com/callstack/linaria#interoperability-with-other-css-in-js-libraries
CSS in JS と比べて dynamic なスタイル定義が弱い( css
タグやprops に副作用があった場合のサポートなどがされていないことが多い)。https://github.com/callstack/linaria#interoperability-with-other-css-in-js-libraries では普通の CSS in JS ライブラリと共存できるので上手く使い分けてねと言っている。
ただ設定とか使い分けとか色々めんどいので、パフォーマンスに関心がないときはわざわざやらないかもしれない
最初 Zero-runtine CSS in JS は CSS in JS の完全進化版かと思ったが、↑にあるようにちゃんとトレードオフはあるっぽい
もっと簡単に CSS in JS でパフォーマンス上げたいw
https://zenn.dev/seya/articles/966efb6ec2a3d8 良さそう
Near-Zero-Runtime CSS in JS なんてもんあるのかw
20:00~ @igsr5 @lemonadern