以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2023/12/16/200703より取得しました。
scopedなCSS
- shadowDOMは独立してて外の影響をうけない
- @scopeは影響を受けたいときに使う
- リンクはglobalなCSSを適用したいとか
- どの親要素からどの子要素の間まで適用するといった感じで範囲指定もできる
- 複雑なクラスをつけなくて良くなって要素セレクタも気軽に?使える
Utility First CSS
- デバッグが大変?
- classに名前がないから
- 開発中はコンポーネント化されてるし気にならない?
- CSSの新しい記法活かしきれるか?
- :hasは独自の書き方で実現はできる
- tailwindとかのツールを学ぶ感じになってしまう?
- KumaUI
- utility classではない
- CSS props
- 型の恩恵を受けたかった
- CSSとJS
- UIに関するstateはCSSに寄せるべき?
- CSSを分からなくてもJSだけで書けるツールが増えてる
- LayoutShift
- zero runtime css
- RSC対応のために流行ってきた面はある
- 元々runtimeに手が入るのでパフォーマンスに課題があった
- なのでRSC対応できればいいというものでもなくちゃんとパフォーマンスも気にするべき
- AIフレンドリー
- AIに吐かせるならtailwindが相性いいらしい
- copilotで補完とかだとファイルまたがない方が相性いいかも
Accessibility
a11yの歴史
開発時のチェック
- ESLintとかaxeとかで静的解析もできる
- 全部をできるわけではない
- 静的解析でOKならいいというわけでもない?
- 人の目で見るにしても思いのある人が見ないとちゃんとチェックできない
- 最近だとa11yに配慮されたコードだとテストが書きやすい
AI
- 画像のaltを自動生成できないか
- コンテキストを把握した上で生成してもらわないといけない
- コンテンツ提供者の意図を含めないといけない
クローリング
- スクロールしないと要素がでないページが増えてきている
Design Technology
- デザインとエンジニアリングは不可分
- デザインという言葉のスコープ広すぎ
デザインシステム
- 用語が曖昧
- 実質的にコンポーネントライブラリのことを指す使われ方も増えている
Frontend Architecture
クライアント/サーバ
- どちらに寄せるか行ったり来たりしている
- 今はサーバに寄り始めてる
- 作るものの性質による
- 認証必要なアプリはSSRする必要もない?
- 速度やSEOなど気にする必要あるならSSRしたい
- Next.js以前は自前でSSRやってた
- SSRは負荷がかかったりパフォーマンスでなくて大変だった
- 自前FWはReactの進化など追従が大変だった
RSC
- サーバだけで動くコンポーネントを作れる
- RSCはSSRしなくても使える
- APIアクセスなどサーバ側でやっちゃえる
- データを取得するところもReactの範疇になってきた
- Reactコアチームの人たちはGraphQLの次のものとしてRSCを考えてる
- fetchしてそこでキャッシュするライブラリが増えてる
プロダクション採用
- 歴史のあるサービスは簡単にUXを変えられない
- 多少の不具合が起きてもいい場所でトライアルしてる
- 同じサービスでも複数アプリ入ってるケースも多くその中で選んだり
以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2023/12/16/200703より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14