00:07
はい、おはようございます。ユメミのkeethこと久保原です。
では本日も朝活を始めていきたいと思います。
本日はですね、実は出張先のホテルで収録してるんですけど、
すみません、これはですね、後からオフレコで音声を入れております。
というのもですね、マイクの認識が悪くてですね、最初の方全然音質が悪く聞き取れなかったので、
改めてそこをカットして今収録をしているところですね。
で、それを後付けで組み込んでます。
今回はタイトルにあります通りですけど、
トランスファラブルスキルズってものと、
Why We're Breaking Up with CSS-in-JSという2つの記事を読んでいる形になります。
1つ目の方は、いわゆるミクロとマクロの視点で、
技術っていうものをどういう風に勉強しているかというと、
その学ぶ技術そのもののカテゴライズをしている感じですね。
後者の方は、エモーションの開発ですね、
メンテナーの方がご自身に書かれたCSS-in-JSをやめるっていう判断をされた2つの記事を読んでますので、
お楽しみというか聞いていただければ幸いです。
それでは本編をどうぞ。
前者の方は、マクロとミクロのプログラミングスキルというところで、
アンリー・オズマニって方ですかね、
技術スキルの2つの大きなバケツにまとめて考える方法というのを紹介していると。
その2つっていうのが、1つはマクロで1つはミクロだというところですね。
コンポーネントを実装するという考えというのがマクロ的な視点で、
ミクロ的なところは概念とか具体的な実装についてのスキルみたいなところですね。
というのを分けて語っているというちょっと短めの記事がありますね。
もう1個はタイトル通りですね。
なぜCSS-in-JSを我々はやめるのかっていうところですね。
CSS-in-JSの代表的なライブラリーであるエモーションというもののメンテナーで、
本人の方が中の方がCSS-in-JSの魅力と問題点について書かれていると。
良い点悪い点を整理して、この執筆者のサムさんですかね。
サムっていう方が書かれているので、そこを読んでいこうと思います。
では早速1つ目のトランスファーラブルスキル図のほうから読んでいこうと思います。
レディ・オサム・オズマニ氏は技術的なスキルについて2つの大きなバケットに分類して考えていますと。
さっそく引用ですね。
マクロレベルでは言語に関係なく転用可能なプログラミングの概念というのを学びますと。
マクロレベルでは言語に関係なく書くとなる考え方というのは同じです。
例えばデータ構造、配列オブジェクト、モジュール、ハッシュとかアルゴリズムですね。
検索とかソートとか。
あとアーキテクチャですね。
デザインパターンとか状態管理など。
あとはパフォーマンスの最適化ですね。
イーガーとレイジー評価とかメモ化、キャッシュ、レイジーローティングとかが含まれます。
これらを頻繁に使う概念なので、逆にすることで多くの価値を得ることができる。
03:02
こういうものがマクロですね。
もう1個ミクロですね。
ミクロのレベルではこれらの概念の実装そのものを学びますと。
これには使用する言語、JS、Python、Rubyなどがある。
使用するフレームワーク、リアクトだったりアンケラビューだったりとか。
あとは使用するバックエンドですね。
Django、Railsなどとか。
あとは使用する技術ですね。
技術スタック、Google App Engine使うとか、Google Cloud Platformとか。
この方は結構Google推しな方なんですね。
AWSとかいろんなものがありますけど。
あります。
このように専門知識を身につけるということは効果的であるけど、
必ずしも転用可能とは限らないよというのが含まれている。
よくある技術スタックというか技術ロックと言ったりするんですかね。
そんなこと言っていた気がします。
なので転用可能かどうかは難しいけどというところがMicroです。
結果的にマクロのほうに皆さんもたどり着くと思いますけど、
入りとしてMicroでもいいんじゃないかという気はしています。
これがいわゆるソフトの部分というところのお話でした。
つまりマクロスキルというのは移植可能なスキルということです。
私はこの点がとても気に入っています。
しっかり学べば技術の変化に応じてそのスキルも一緒に移動することができますと。
新しいフレームワークが導入されたというと、
それはそれでいいんですけど、
エリーが言うように構文は違っても格となる考え方は同じというところですね。
で、デイブという方が出てきて、
この方がいつ言ったか覚えていませんけど、
彼が言っていたことは知っていまして、
私の頃に思っていますと、
私たちはウェブ開発におけるコンポーネントの一般的な考え方について話していました。
コンポーネントにはたくさんのアプローチがありますが、
基本的にはすべて同じ概念モデルというのを共有しています。
スコープだったり、コンポジションだったり、
カプセル化、ネスト化などなどというところですね。
前回の講演でそういうのをスライドでしゃべりましたと。
要はコンポーネントはマクロであり移植可能な概念であるというのが、
この方の結論だというところですね。
はい。
以上、結構短いですけど唐突に記事を終わってしまいました。
ただ、マクロとミクロというところのお話ですね。
とても共感もあるし、まさにその通りだなというところで、
ただ、僕の周りとか若い方はミクロのレベルから入っていくとか、
ミクロを極めていくという方は結構多いのかなという、
なんとなく印象はありますけど、
最終的にビジネスとかアプリケーションシステムとして
ちゃんと動かすというところになると、
やっぱりマクロ視点のものをどんどん考えていかなきゃとか、
それを対応していかないといけないというのはすごくあると思うので、
ここは時間の問題でもあるし、
最初からマクロから入ればいいというのはもちろん意味でもないですけど、
プログラミング最初はたぶん楽しいと思ってもらっているとか、
ものがちゃんと作れるという経験をしていただいて、
そこからマクロに行くのは絶対いいと思うので、
僕は結構ミクロから入るのはいいと思いますけど、
ミクロだけを極めるのが、
そしてエンジニアとしてどんどんというのがすごくあるので、
やっぱりマクロも一緒に学んでいくというのがいいんじゃないかと思います。
ただ、マクロとミクロというのはしっかりカテゴライズとか、
分けて物事を考えていくのが大事だなというふうに感じました。
ではでは、今のが一つ目の記事、
トランスファラブルスキルズという、
06:01
転用可能なスキルというところでした。
では続いてもう一個の方ですね。
こっちが本題です。
Why we are breaking up with CSS in JS?
CSS in JSをなぜやめるの?という話ですね。
こっちはちょっと長いので、
もしかしたら教授に読めないかもしれない、
読み切れないかもしれないんですけど、
ゆるーく読んでいくのでお付き合いいただければ幸いです。
冒頭で申し上げましたけど、
今回はSAMという方が書かれているんですけど、
この方はエモーションのメンテナーですね、
中の人がそのCSS in JSの良し悪しというのを語っているという記事になります。
こんにちは。
スポットのソフトウェアエンジニアで、
リアクト用のCSS in JSライブラリを広く普及しているエモーションの
2番目に活発なメンテナーであるサムと申します。
2番目に活発なんですね。
この記事で私がもともとCSS in JSに惹かれた理由と、
私とそのスポットチームの他のメンバーが
CSS in JSから離れることを決めた理由について誇り下げます。
この方も離れることを決めたんですね。
だけどエモーションはメンテナーとして2番目にコミットしていると。
面白いですね。
ちょっと興味深いから読んでいきましょう。
まずCSS in JSの概要とその長所短所を説明します。
そしてスポットでCSS in JSが引き起こしたパフォーマンスの問題を
深く誇り下げ、どうすればそれを回避できるかというのを
今日はお話しをしようというところでした。
冒頭からインパクトがあって気になりますね。
本文入っていきましょう。
まずはWhat is CSS in JS?
ちゃんと丁寧にCSS in JSとは何ぞやみたいな話から入れようと思います。
CSS in JSとは名前の通りJavaScriptやTypeScriptのコードに
直接CSSを記述することで
リアクトコンポーネントのスタイルを設定することができます。
リアクトだけに留まらないですけど、とりあえずリアクトを例にしています。
リアクトコミュニティではStyled Componentsというライブラリと
Emotionというライブラリですね。
最も有名なCSS in JSライブラリといったらこの2つだと思います。
私はEmotionしか使ったことがありませんが、
本記事のポイントはほぼすべてStyled Componentsにまで
はまるというふうに思います。
大体一緒ですね。
EmotionはStyled Componentsの機能も内包していますから。
この記事ではStyled ComponentsとEmotionの両方を含む
ランタイムCSS in JSというものに焦点を当てます。
ランタイムCSS in JSとは簡単に言えばアプリケーションの実行時に
ライブラリがスタイルを解釈し、適用することとなりにします。
コンパイル時のCSS in JSについては記事の最後に
簡単に説明しますよということでした。
このような問題というのはクラス名を長くしたり、
より特定のセレクターを使用することでも一応解決はできますけど、
クラス名の衝突がないことを確認するのは
開発者の自身であるあなただと言っています。
CSS in JSというのはデフォルトでスタイルを
ローカルにスコープすることでこの問題を解決しています。
もしあなたがリストビューの業務を次のように回答します。
リストビューのコンポーネントですけど、
ざっくりと言いますけど、
divタグがあってアトリビュートにそのままCSSを書いています。
CSSイコールパディングホゲホゲボーダーホゲホゲみたいな
アトリビュートで設定すれば基本的には
09:01
分離できてますよねという話です。
昔のCSSはそういうふうな書き方をしていましたけど、
今はそのCSSファイルに切り出してクラス名で
名前を分けているという感じですよね。
こんなふうにでも書けばパディングやボーダーが
無関係の要素に誤って付与されることがないと。
注意書きとしてCSSモジュールというのは
ローカルにスコープされたスタイルも提供していますよ
ということを言っています。
こういうことをCSSにJSを使えば
同じことを再現できる。
でもプログラミングのコード的には分けたような書き方
見た目になるのでどちらも問題解決していいねという話ですよね。
スタイルを直接アトリビュートに書くと
パフォーマンスの話どうなのというのが
多分焦点だと思うので
これが今から出てくるんだろうなと思いますね。
この後です。
続いて2つ目です。
2つ目はコロケーションというところが
メリットと言っています。
プレーンなCSSを使用する場合
全てのCSSファイルを
ソーススタイルツールというディレクトリに
とりあえず置いておいて
全てのリアクトコンポーネントを
ソースコンポーネントに置くかもしれないです。
よく見るディレクトリ構成ですね。
アプリケーションのサイズが大きくなると
どのスタイルが各コンポーネントで使用されているか
すぐに見分けることが難しくなります。
多くの場合
スタイルが使用されていないことを
簡単に判断する方法がないため
CSSにレッドコードが乗ってしまうということもあります。
まあまあこれもよくありますね。
コードを整理するための
より良い方法というのは
1つのコンポーネントに関するものを
全て同じ場所に含めちゃうことです。
この方法はいわゆるコロケーションと呼ばれて
検討士ドッツ氏による
素晴らしいブログ記事でも紹介されています。
その素晴らしいブログ記事も
本記事内にリンク貼られるので
興味ある方は見てみてください。
CSSとJavaScriptは
別々のファイルに記入する必要があり
.cssファイルというのが
どこにあるかに関わらず
スタイルがグローバルに適用されるからですと。
一方CSSにJSを使用する場合は
スタイルを使用する
リアクトコンポーネントの内部に
直接スタイルを記入することができます。
正しく行えばアプリケーションの保守性というのを
大幅に向上させることもできます。
注意書きとして
CSSモジュールでも同じファイルではありませんが
スタイルをコンポーネントと
ロケットすることは一応できますよと。
続いて
メリット三つ目の話ですね。
三つ目ですけど
スタイルの中でも
スタイル内でJavaScriptの変数を利用できる
CSSにJSを使うと
スタイルルールの中でJavaScriptの変数を
参照することができるようになりますと。
これ大きいですよね。
全部JSで管理できるから。
実際に画面上の挙動であって
ユーザーの操作によってスタイル変えたいときは
絶対あると思うので。
一応ソースコードの例で出てますけど
皆さんがよく見たことあるような感じです。
とりあえずエクスポートコンソで
Colorsってのを
プライマリーほげほげボーダー
なんちゃらってのにしてあって
実際にJSXの中の方で
例えばPタグがあったとして
PタグのCSSの中で
JS変数さっき使った
Colorsってのが呼び出せると
12:01
さらに設定できると。
Colors.borderなのか
Colors.primaryなのか
というのはバイケースで
変更できるというのが大きいよね。
この例のように
CSS in JSのスタイルでは
JavaScriptの定数
色などとかを
PropsとかStateとか
フォントサイズの両方を使用することが
可能になります。
スタイルでJavaScript定数を
使用することで
同じ定数をCSS変数とJavaScript定数の
両方として定義する必要がないため
場合によっては
重複というのを減らすことができます。
PropsとStateを使うことで
インラインスタイルというのを使わずに
カスタマイズ性の高いスタイルを持つ
コンポーネントを作ることもできます。
インラインスタイルというのは多くの要素に
同じスタイルを適用する場合
パフォーマンスの目で理想的ではありませんよね
という話もしていました。
以上3つが一応CSS in JSを使うときの
メリットというところですね。
続いて
The Neutralですね。
どちらでもないような感じの
人たちというところですね。
ここのメリットは一つしかないそうですね。
話題の
新技術というのから私を含め
多くのウェブ開発者というのは
JavaScriptのコミュニティで最もホットな
新しいトレンドをすぐに採用します。
多くの場合新しいライブラリや
フレーマというのは以前のものより
大幅に改善されていることが
証明されているからです。
リアクトがJQueryなどの以前の
ライブラリよりどれだけ生産性を
向上させているかというのを考えてみてください。
そこを私たちがピカピカの新しい
ツールにこだわるのはさらに
まさに脅迫観念です。
新しいライブラリやフレームワークを
採用する際、次の大きなものを
見逃してしまうことを恐れ、本当の
欠点を見落としてしまうかもしれません。
CSSJSが広く採用されたのも
このことが要因の一つであった
というふうに思います。
なかなか
資産の高いご意見ですね。
なるほどね。
ある種の脅迫観念において
CSSJSがこれだけ皆さん流行ったと。
CSSとかスタイリングの書き方って
確かにいろんな書き方ありますけど
結局デムとか
クロックスとかいろんな
いわゆるオブジェクティブCSSみたいな
観念の
名前空間の拡張の方に
一時は走っていた。
今も全然そのやり方は
全世界でも使われていて
僕もそれは素晴らしいと思いますけど
それが良いかどうかというのが別として
そんなものしか出てこなかったのに
新たな
CSSにおけるアーキテクチャというか
仕組みというのが導入されて
全世界で一気にプワッと流行ったんですけど
もちろん便利なことは分かっていますし
皆さんそれの利用価値が
高いというのを知って導入されているとは思うんですけど
それでもある種脅迫観念もあるんじゃないの
というのがこの
M4の中の方がおっしゃっているのが結構面白いなと思いました。
ただの感想ですみません。
続いてじゃあいきましょう。
続いてザ・バットですね。
ここから悪い点について語られています。
こちらも3つです。
ちょっと端的に語られていますがいきましょう。
15:01
1つ目はCSS in JSというのは
ランタイムオーバーヘッドを追加するというところが
1つのバットです。
コンポーネントがレンダリングされるとき
CSS in JSライブラリというのは
あなたのスタイルをドキュメントに挿入可能な
プレーンなCSSに一回シリアライズしないといけません。
これが余分なCPUサイクルを
消費することはもちろん明らかですけど
アプリケーションの性能に
顕著な影響を与えるほどでしょうか。
次のセクションでこの2問についても
詳しく調査をしています。
ただオーバーヘッドが発生するのは事実ですよね。
2つ目です。
2つ目はCSS in JSはバンドルサイズを
増加させるにもよって
生み出されるファイルが増えるということです。
これは明らかですよね。
明らか中の明らかですね。
あなたのサイトを訪れたユーザーは
CSS in JSの
ライブラリのJavaScriptをまずダウンロードしなければ
ならなくなりました。
エモーションというのは
MinにしてさらにZipにしたとしても
7.6KB、スタイルコンポーネンツは
12.7KBあります。
どちらもそれほど大きなライブラリではないですけど
それなりにサイズは大きいですよね。
ちなみにReactプラスReact DOMは44.5KBですね。
いくら
スマホの性能が上がったりとか
ハードウェアのスペックが上がったとはいえ
このファイルサイズは
スマホに読み込ましてからやっと
アプリケーションが動くというのは
確かにどうなのというのは疑問にはなりますよ。
それだったら普通に
名前分けしたCSSをベタベタ書いたほうが
ファイルサイズは小さくなりますよね。
3つ目です。
3つ目のBATは
CSS in JSというのは
React DevToolsを散らかしますと。
散らかすという言い方はちょっと面白いですけど
言いたいことが分かりました。
CSSプロップを
使用する各要素に対して
エモーションというのは
プロップインターナル
プロップインターナル
インターションですね。
インサーションですね。
ひどいな。もう一回言いますね。
エモーションは
CSSプロップインターナル
インサーションというコンポーネントを
レンダリングしますと。
多くの要素でCSSプロップを
使用している場合は
エモーションの内部コンポーネントは以下のように
React DevToolsを非常に煩雑にしますと。
今画像を貼られているんですけど
めちゃめちゃネストしますって話をしています。
エモーションを導入すると。
結局
めぐれっぷするのがすごく大変だ
ってことで視認性とか検索性が悪くなる
っていう風に言ってます。とにかく
エモーションCSSプロップインターナル
っていうのとその下にインサーションというのが
どんどん挟まってしまって
みずらって感じになってます。
これが3つ目のBADでした。
続いて
The Agreeですね。これは
さらに悪いという
悪というか嫌悪に近いところですかね。
見にくいもの
っていう風に訳されました。
The Agreeの1つ目ですね。
1つ目はCSSルールを
頻繁に挿入すると
ブラウザに多くの余分な作業を強いることになります。
リアクトコアチームのメンバーで
リアクトフックスのオリジナルデザイナーである
セバスチャン
マーク
18:01
ベイジ
読み方は分からないですけど
リアクト18の
ワーキンググループで
リアクト18で動作するために
CSSインジェースライブラリがどう変わる必要があるのか
また一般的に
ランタイムCSSインジェースの将来について
非常に有益な議論を書いています。
特に彼はこのようにおっしゃっています。
同時レンダリングでは
リアクトはレンダリングと
レンダリングの間に
ブラウザに委ねることができます。
コンポーネントに新しいルールを挿入した後
リアクトが降伏すると
ブラウザはそれらのルールが既存のツールに
ツリーに適用されるかどうか
というのを確認する必要があります。
そのためスタイルルールが
再計算されてしまいます。
次にリアクトが次のコンポーネントを
レンダリングするとそのコンポーネントが
新しいルールを発見しまた同じようなことが起きます。
これによって
リアクトがレンダリングした間
全てのドムノードに対して
全てのCSSルールが
フレームごとに再計算されることになります。
これは非常に遅いですよね。
というのが一つの悪い点です。
なるほどでした。
JSの処理自体の方は
確かに意識していたけど
CSSのスタイルがそもそも再計算される
というのしか意識していなかったので
これは確かに見にくいと言ってもいいかもしれないです。
一応
さっきのセバスチャンという方が
書いていたブログも
この記事内にリンクちゃんと貼っていましたので
見てみてください。
アップデートが来ましたね。
2022年10月25日の追記が一応書いていました。
セバスチャンの
この引用というのは
Use Insertion Effect
というのを使用しない
リアクト・コンカレントモード
パフォーマンスについて特に研究されているものだったそうです。
このことについて深く理解したい場合は
そのディスカッションを全文読むことをお勧めします。
Twitterでこの不正確さを
指摘してくれた
ダンという方には感謝します。
この問題の最悪な点というのは
ランタイム
CSS in JSの文脈の中で
修正可能な問題ではないということ。
ランタイムCSS in JSライブラリ
というのはコンポーネントが
レンダリングするときに
新しいスタイルルールを挿入することで動作しますけど
これは根本的なレベルで
パフォーマンスに悪い影響を与えると。
根本的な設計思想が
パフォーマンスに影響を与えるということですね。
なるほどでした。
続いて2つ目ですけど
The Agreeは2点しかなかったそうです。
2つ目です。
CSS in JSの場合特にSSRや
コンポーネントのライブラリを使用する場合
うまくいかないことがたくさんあると。
MotionのGitHubリポジトリには
たくさん寄せられています。
例えばですけど1つ例が張られていて
Emotionでサーバーサイドレンダリングと
MUIとかマンタインとか
そのいろんなUIフレームわけですね。
別のEmotionのコンポーネントライブラリを
使っているんですけどこれがうまくいかないよ
というふうに言っています。
サードパーティーとかエコシステムとの親和性が
どんどん悪くなっているというところがある
ということですね。
Emotionのインスタンスが
複数同時にロードされてしまいますと。
あと複数のEmotionが同時にロードされるため
同じバージョンのEmotionであっても
21:01
不具合が発生することもあります。
例のイシューが張られていますと。
他にはコンポーネントの
ライブラリ。
コンポーネントライブラリというのは
スタイルの挿入順序を完全に制御できていないことが多いと。
できないって決まってるんだったら
制御できるけどできていないこともある
というのが厄介ですね。
続いてEmotionのSSRサポート
というのはReact17とReact18で
異なる動作をしている。
これはReact18のストリーミングSSRとの
互換性のために必要なことです。
これらの複雑さの原因というのは
評算の一角に過ぎませんし、
勇気があればEmotionスタイルの
タイプスクリプト定義を見てみてください。
勇気があればというところがなかなか
面白いですね。それだけ沼なんだな
というのがよく分かりました。
Reactは結構最近ドラスティックな進化が
本当に大きいですね。
メジャーバージョンアップにつれて
どんどんでかいことが入っていって
それに各種対応しなきゃいけない
エコシステムは本当に大変だと思いますし
それに追いつかなきゃいけないので
いろんなケースが出て
OSSの界隈というのは
カオスになるなとちょっと思いますね。
でも次のReact18もそうですし
新しいところですかね。
それに対応したNext.jsもそうですけど
いろんなところのライブラリとの
関わり合いだったりとか
関係性が大きな課題になってくるし
僕ら開発者がそれを最終的に
メンテしなきゃいけないとか
おもりしなきゃいけないのってなると
それはすごく大変なので
とりあえずエモーションの中でこういうような
他のエコシステムとの関わりとの
イシューがたくさん出ていますと
根本的な原因はもちろん様々ですけど
共通するテーマというのは基本的には
そういう関係性のところだというところですね
興味ある方はタイプスクリプト定義を
見てもらえると分かると思います
ということでした。
時間が迫ってきまして
次からパフォーマンスディープダイブ
というセクションに入るんですけど
これが本セクションの本題であり
メジャーなところなんですけど
中途半端に終わってしまうとそれはもったいないので
一旦ここで区切らせていただきたいと思います
明日はこれの続きを読んでいこうと思います
とりあえず今日はSSNJSの良い点、悪い点
そしてニュートラルと
見にくいところみたいなところ
のご紹介で
一旦区切らせていただいて
これをベースに明日話し続けていきたいと思います
というわけで今日は
こちらで以上ということで
今日ご参加いただきました
皆さん大変ありがとうございました
大地さん、たくみさんと江戸賢治さんと
ゴソウロップさん
なかなか面白いお名前ですね
あと達也長さんですね
ご参加いつもありがとうございます
また明日も緩く読んでいきたいと思います
では金曜日ですね
一週間の締めということで
頑張って良い休日を過ごしていただければ幸いです
終了したいと思います
お疲れ様でした
