00:05
はい、11月12日、土曜日ですね。 遅刻は朝9時を回りました。
えー、やっと家に帰ってきましたけど。 まあやっぱり自宅が一番いいですね。気楽だし休めるなという感じですね。
はい、じゃあおはようございます。 keethこのくわはだです。 では本日も朝活を始めていきたいと思います。
で、昨日からですね、Why We're Breaking Up with CSS-in-JS という記事を読んでいます。
CSS-in-JSで有名なライブラリー、Emotionのメンテナーですね。 中の方が書かれた記事になります。
タイトルにある通りですけど、 CSS-in-JSを辞める方向に走ったんですね。
ちなみにこの方、サム・マグラさんって方ですけど、 一応Emotionへのコミットのランキングがわかんないですけど、第2位だそうですね。
2番目にコミットしている方だということで、 その方がCSS-in-JSを辞める方向に走ったっていうところで、
なかなか興味深いなというところですね。 昨日はその良い点悪い点と、見にくい点というところですね。
CSS-in-JSのお話を昨日ザーッとダラダラ読んでた感じです。 結構共感ばっかりのお話だったし、
仲の人なので、より多分深い視点の中でのご意見だと思うので、 説得力もあるし、とてもいい話だなというところでしたね。
今日はその続きで、 CSS-in-JSのパフォーマンスディープダイブというところから今日入っていこうと思います。
そうなんですよね、CSS-in-JSで一番議論というか、 辞めるかどうかの論点の的になるのは大体パフォーマンスのお話だったりするので、この辺ですね。
僕も過去に1回ちょっと大きいECサイトのお客さんのお仕事を 手伝っていただいたことがあって、
その時の設計にCSS-in-JSのスタイルコンポーネンツを使っていたんですけど、 そのスタイルコンポーネンツが途中でやっぱりそれを引っかかそうという話になったんですね。
というのもやっぱり巨大になっていけばいくほど、 パフォーマンスが本当に悪いし、ビルドも時間がかかってしまって、
結果ビルド後の出力のファイルもやっぱり容量が大きくなって、 やっぱりよろしくないよねというのでやめた感じですね。
で、そうですね、そのスタイルコンポーネンツを引っかかすということですね。
コンポーネントの数も何十?100近くいったのかな? 行ってないか忘れましたけど、結構巨大なアプリケーションで、
かつやっぱり結構設計に重きを置く会社さんだったんですね。
なのでやっぱり技術知見とか知識すごく高い方ばっかりの中での開発だったので、
僕としては経験値も上がったし学びになって良かったんですけど、
ただやっぱスタイルコンポーネンツは重いねっていう結論はどうしても変わらなくて、
なんとか無理やり、一人二人の人が通常の開発業務とは別で引っかかすようなチケットを担当されてましたね。
それぐらい経験があって、やっぱりどれだけ大きくなればなるほどスタイルコンポーネンツは よく遅くなるって話はその通りだという感じはしてます。
というところで入っていきたいと思います。パフォーマンスディープタイプですね。
今日はケンジさんですね。お参加いただきありがとうございます。
じゃあ今からちょっとダラダラ読んでいこうと思います。
03:00
パフォーマンスディープタイプ。この時点でランタイムCSSインジェースには大きな長所と大きな短所があるってことが前回まで読んだ範囲では明らかになりました。
私たちのチームがこの技術から離れる理由を理解するためには、CSSインジェースの現実のパフォーマンスへの影響というのも探り必要がありますよと。
ここではそのスポットっていうサービスですね。この方がお仕事されているところですけど、スポットのコードベースで使用されていたエモーションのパフォーマンスへの影響についてちょっと焦点を当てていきましょうと。
エモーションには様々な使い方がもちろんありますし、それぞれにパフォーマンスの特性もありますよってところです。
っていうのが前提で、一発目はシリアライゼーションインサイドブレンダーVSアウトサイドブレンダーってところですね。
レンダー内のシリアライズとレンダー外のシリアライズと、ところから入っていきたいとですね。
スタイルのシリアライゼーションとは、エモーションがCSS文字列やオブジェクトスタイルを受け取って、ドキュメントに挿入可能なプレーンなCSS文字列に変換する処理のことを指しますと。
まあそういうことで結局は文字列にして組み込むしかないってことですよね。
で、エモーションはシリアライズの際にプレーンCSSのハッシュっていうのを一旦検査していきますと。
このハッシュは例えば、CSF-15NL2R3みたいな適当な文字列、ハッシュを作っておいて、
その生成されたクラス名にそれを表示するというところですね。
で、ちゃんと計測したわけではないんですけど、リアクトのレンダーサイクルの内側と外側でスタイルのシリアライズを行うかどうかっていうのが、
エモーションのパフォーマンスに最も大きな影響を与える要因としたというふうに、この方は考えているというところですね。
ちゃんと取ったわけではないので予測の意見は出ないですけど。
で、エモーションのドキュメントにあるサンプルでは、このようにレンダー内の内側でシリアライズを行っていますと。
で、一応ソースコードがバッと貼られてますけど、特にそんなちゃんとシリアライズしたかっていうような感じのソースコードではないですね。
普通にファンクションマイコンポーネントっていう関数コンポーネントがあって、
レンダーでJSXが入ってあって、ディブタグ1個ガンと置いてあるだけですね。
で、そのアトリビュートにCSSイコール並み括弧で、それぞれのスタイリングが設定されているという、それだけの話ですね。
っていうことをやっています。で、このようにレンダー内の内側で結局はシリアライズを行っているっていうのが、
エモーションのドキュメントサンプルだと言っています。まあまあこれよく見るソースコードですね。
で、マイコンポーネントで今言った関数コンポーネントですね。
マイコンポーネントがレンダリングするたびに、オブジェクトスタイルっていうのが再びシリアライズされますと。
で、マイコンポーネントが頻繁にレンダリングされればいいですね。例えばキーストロークの旅とか。
そのためにレンダリングされる場合っていうのは、シリアライズの繰り返しっていうのは高いパフォーマンスコストをもたらす可能性がありますと。
で、よりパフォーマンスの高いアプローチっていうのは、スタイルをコンポーネントの外側にとりあえず移動しておいて、
シリアライゼーションが各レンダリング時ではなく、モジュールのロード時に1回だけ行われるようにすることです。
で、これは、at emotion slash reactというライブラリがあって、そっちのCSS関数で行うこともできますよと。
06:04
今言った、divタグに直接CSSイコールホゲホゲみたいな内側の方での設定をするのではなくて、
外側の方でconst myCSSイコールCSSっていう関数を呼び出して、その中でオブジェクトでスタイリングの設定を置いておく。
で、そのmyCSSみたいな変数をdivタグのCSSのとこにガンと入れちゃうっていうのがエモーションのやり方ですね。
よく見るのは多分こっちだと思います。直接書いてもいいっちゃいいんですけど、確かに分かりやすいというか。
いいんですけど、やっぱり僕はあんまりHTMLとかDOMそのものにCSSをアトリビュースで書くのはやっぱ好きではないというか。
家族性悪くなりますし、やっぱりHTMLはHTMLだけとしていきたいのが僕の思想ではありますね。
あと、汎用性悪くなりますからね。
というのと、この方がおっしゃっていた通り、頻繁にレンダリングされるとそのたんびにそのCSSも再計算されるっていうので、
それは確かにパフォーマンスコスト悪いので、外側に書いてロードされるときだけっていうのが一番いいと思いますね。
もちろん、これではスタイル内のプロップにアクセスはできないので、CSSインジェースのセールスポイントの一つを逃しているという欠点はもちろんあります。
スポットではレンダーでスタイルのシリアライズを行ったので、以下の性能分析ではこのケースを中心に説明します。
ここからその性能分析の話をしていくけど、基本的には外側と内側のシリアライズっていうところからの立脚した意見になりますよってことですね。
外側にする分、セールスポイントを1個逃しているが、でも内側にすると毎回レンダリングのときの再計算とパフォーマンスコストがかかって、その対比だってことですね。
じゃあいきますかね。続いて。
その対比の一つ目はメンバーブラウザーのベンチマークです。
いよいよスポットというサービスの実際のコンポーネントをプロファイリングして物事を具体的にしていく時がきました。
今回はメンバーブラウザーを使用しています。メンバーブラウザーはチーム内の全ユーザーを表示するシンプルなリストビューだと言っています。
そのメンバーブラウザーのスタイルにはエモーションのCSSプロパティが使用されています。
メンバーブラウザーって名前が付いているけど、サービスっぽい感じですね。
エモーションのCSSプロパティというのが使われていますよと。
for the test、テスト用でやっているものとしてはメンバーブラウザーにまず20人のユーザーが表示されます。
リスト項目の周りにリアクトメモが削除されます。
一番上のブラウザーメンバーズというコンポーネントがあって、そのコンポーネントを毎秒レンダリングするようにします。
しかも毎秒レンダリングするように強制して、最初の10回のレンダリング時間を後で記録しています。
ラストにリアクトストリクトモードというのをオフにしています。
プロファイラーに表示されるレンダリング時間が実質的に2倍になりますよと。
あ、そうなんや。ストリクトモードをオフにするとレンダリング時間が実質的に2倍になるんですね。
09:03
これちょっと知らなかったな。
そういうことをやっていました。
こういうことをやった結果、リアクトデブツールズを使用してページをプロファイリングしたところ、
最初の10回のレンダリング時間の平均はだいたい54.3ミリ秒でしたということですね。
これは別に早いんじゃないですか。
私の個人的経験則では、リアクトコンポーネントのレンダリング時間は16ミリ秒以下であるべきだと考えています。
えー、そうなの。
1秒間に60フレームの場合、1フレームは16.67ミリ秒だから、そういうことですね。
という意味で、そこが理想ではあると。
メンバーブラウザーは現在この数値の3倍以上なので、かなりヘビー級なコンポーネントと言えるでしょう。
逆に言うとそういうことですね。コンポーネントはデカいってことですね。
このテストは一般的なユーザーが持つCPUよりも、
WAIってなんだ。WAIってわざわざ大文字で書いているから、それは多分ネットスラングなんだろうな。
WAIで高速なM1マックスのCPUで行われました。
で、54.3ミリ秒のレンダリングタイムというのは、精度の低いマシンでは200ミリ秒になる可能性もありますよと。
高速なM1マックスのCPUでもそんな時間をかかっているとは結構遅いですね、これは。
フレームグラフの解析というのが次に行きますね。
その上記のテストから得られた1つのリストアイテムのフレームグラフというのをとりあえず表示してみました。
この画像を見てみるんですけど、膨大な数のBOXというコンポーネントとFLEXというコンポーネントが連打にされています。
ありがちですよね。スタイルコンポーネントもそうですし、エモーションでもそうですけど、よく作るコンポーネントだと思います。
BOXコンポーネントとかFLEXコンポーネントで確かによく作るし、使い勝手いいのでめちゃくちゃ大量に使う気がしますね。
実際今回のSpotというサービスでもプロファイリングをとってみたフレームグラフを表示すると、
その2つの汎用的なコンポーネントが大量に連打にされていると。
これらはCSSプロパティを使用するスタイルプリミティブというものになります。
各BOXというコンポーネントの連打には0.1から0.2ミリ秒ですね、近くかからないです。
1個1個は確かにかからないんですけど、BOXコンポーネントと合計数が膨大であるためこのような結果が生じます。
やっぱり汎用的なコンポーネントは使い勝手いいし、単発では全然短いんですけど、結局チリツモというお話ですよね。
なのでこの辺はやっぱりドムの設計をちゃんとできるというのはすごく大事なんだなと思いますし、
つくづく感じるのは結局ブラウザーというのをHTMLで表現するというところに尽きるので、
HTMLの数が少ないに越したオーダーはもちろんないというお話ですね。
なので無邪気にDivタグを使わないほうがいいって感じですかね、そしたら。
では続いて、ペンジマーキング・ザ・メンバーブラウザー・ウィズアウト・エモーションですね。
続いて、エモーションを除いた場合のメンバーブラウザーというサービスのベンチマークのお話です。
このレンダリングコストがエモーションのせいなのか、それともエモーションの代わりにSASモジュールを使ってメンバーブラウザーのスタイルを書き直してみましたよと。
SASモジュールというのは、ビルド時にプレーンなCSSにコンパイルされるのでパフォーマンス上のペナルティはほぼないよという話だそうです。
上記のテストもちょっと繰り返しましたと、同じように。
12:02
最初の10回のレンダリングの平均は27.7ミリ秒でした。
これは元の時間から48%を短縮されることになると。
なると、やっぱりエモーションのせいなんじゃないの?という予測が立ちますね。
つまり、これが私たちがCSS in.jsと決別する理由だったそうです。
ランタイムパフォーマンスのコストが高いんだというのがCSS in.jsの欠点だと。
この結果は、Spotというサービスのコードベースとエモーションの使用方法にのみ直接適用されるものです。
もしあなたのコードベースがよりパフォーマンスの高い方法でエモーションを使っているならば、
例えばレンダーの外側でスタイルをシリアライズしているとかであれば、
CSS in.jsを方程式から外した後の結果はあんまり効果はないのかなり小さいと思われます。
なるほどね。
けど今回のこの筆者の方、Spotというところではめちゃめちゃ効果高く、
少なくとも半分近くパフォーマンスは削減できたと。
一応気になる方のために生データを紹介しますということで、
単純にこれスプレッドシールドのリンクパッと貼られてるんですけど、
10回テストしたところ、with emotionとwithout emotionという列があって、
それぞれで比較してるんですけど、
だいたい半分ぐらいの数字になっているというところですね。
minで48.6と20.5ミリ秒です。
パフォーマンスのパーセントチェンジとしては57.8%の削減。
maxで56.6と34.1のミリ秒だと。
こっちだと39.8%で間を取るとだいたい48%削減できているということで、
emotionない方がいいじゃんっていうのが結論そうですね。
繰り返しますけど、この方はそのemotionのコミッターで、
しかもコミットランキングっていうのがあるっぽくて、
それの第2位だそうですね。
で、その方がGSSにJS離れるって決断をしたっていうのが本当に興味深いですね。
やっぱりちゃんとエンジニアというか、必要だからツールを使ってる技術を使っている。
でもやっぱりエンドユーザーのために重くなったら遅くなるんだったら
技術を引っかかすっていうのも全然実はないっていうのはとてもいい。
やっぱりエンジニアだなと本当に思いましたね。
こういうスタイルっていうのが、スタンス感。
はい、余談でした。
じゃあ続いていきましょう。
Our New Styling Systemというところで、
新しいスタイリングシステムのお話が次に続くそうです。
CSS in JSから脱却することを決した後、
当然の疑問としてその代わりに何使うのっていうのがありますよと。
理想的にはCSS in JSの利点をできるだけ活かしつつも、
普通のCSSと同じようなパフォーマンスを持つスタイリングシステムを作りたいと。
両方欲しいよねそれはね。
で、まあ以下はその良い点、グッとパートでですね、
説明したCSS in JSの主な利点ですよと。
改めて利点を書きますと3つありますと。
スタイルがまずローカルにスコープされる。
まあこれが一番大きいかもしれないですね。
で、スタイルは適用するコンポーネントと一緒に配置されます。
で、スタイルにJavaScriptの変数が使える。
っていうのがやっぱりそのCSS in JSの3つの大きな魅力だったと。
で、このセクションを読んでいれば、
CSSモジュールもローカルスコープと伝えると、
コロケーションっていうのを提供する、
というのを述べたことを思い出されるでしょう。
で、またCSSモジュールはプレーンなCSSファイルにコンパイルされるため、
15:01
CSSモジュールを使用することによる、
実行時のパフォーマンスコストはもちろん発生しません。
で、私の考えるCSSモジュールの主な欠点は、
結局のところプレーンCSSであることにあんまり変わりはなく、
プレーンCSSにはDXを改善し、
コードの重複を減らす機能っていうのがやっぱり欠けていますよと。
あのプレーンCSSって要は言語に過ぎないので、
そこまでDX改善だったり、
重複を減らす機能があるかっていうと、
言語にそれを求めるのはちょっと難しいですね。
ツールそのものに使い勝手はもちろん考えたらいいと思いますけど、
ここは、僕はちょっとなんか、この主張はむずいなと思いましたね。
もちろんあるに越したことないし、
そんなのがあったらめちゃくちゃ嬉しいですけどね。
まあいろんなエディターだったりとか、
サードパーティーのエコシステムライブラリーとかで、
検知したりするとかっていう感じで今のところなっていると思います。
で、ネストされたセレクターっていうのがCSSに導入される予定ですね。
これはもう既に、結構ステージいくつだっけ?
進んでるっぽくて、ネストCSSは多分現実的に導入されるっぽいですね。
これをすごい僕期待してます。
で、まだ導入されていなくて、
この機能は私たちにとって大きなQOLの向上となります。
結局ネストっていうのが入ると、それでもだいぶ解決するんですよね、物事はね。
っていうところが大きな期待ですよと。
で、幸いなことに、この問題には簡単な解決策が一応あります。
SaaSモジュールっていうのが単にSaaSで書かれたCSSモジュールっていうのがありまして、
CSSモジュールのローカルにスコープされたスタイルとSaaSの強力なビルドタイム機能っていうのを
ランタイムコストなしで利用することができると。
このためこのSaaSモジュールというのは今後汎用的なスタイル付けのソリューションになると思われます。
SaaSモジュールって言ってるけど、いわゆるSaaSのことだよね。
いわゆるSaaS、SCSSの話のことだと思います。
で、補足を一応しておきますと、SaaSモジュールではCSS in JSのリテム3ですね。
スタイルでJavaScriptの変数を使用する機能っていうのがその限り失われますと。
あくまでSaaSはオールドCSSみたいなもんですからね。
で、しかしSaaSファイルのエクスポートブロックを使ってSaaSのコードからJavaScriptに定数を利用できるっていう風にすることは一応可能ではあります。
これはあまり便利ではないですけど、ドライな状態を保つってことはできるのでその魅力もありますよねってことでした。
で、続いてUtility Classesのお話に移るそうですね。
ってことは多分Tailwindの企画が来るのかな、ここから。
はい、じゃあUtility Classesです。
EmotionからSaaSモジュールに変更する際にですね、チームが懸念していたことっていうのは、
例えばDisplay://flexのような極めて一般的なスタイルの適用が不便になることでした。
以下は以下のように書いてました。
以前は以下のように書いてたところで、flex-hっていうコンポーネントがあって、
AttributesにAlignItems="center",みたいなそういう書き方をしていたと。
なんか昔ながらのCSSスタイリングっぽい書き方をしているようには見えますね。
懐かしいというか、まさにUtility Classって感じはしますけど。
SaaSモジュールだけを使ってこれを行うには、.module.scssファイルを開いて、
Display://flexとAlignItems="center",のスタイルを適用するクラスってのを作成する必要があります。
18:04
これで終わりというわけではありませんが、利便性が悪くなるのはもちろん間違いないと。
この辺りのDXを改善するために、いわゆるUtility Classという仕組みを持ち込むことにしましたよ。
Utility Classをご存じない方のために説明すると、要素に一つのCSSプロパティを設定するCSSクラスです。
通常は複数のUtility Classを組み合わせて、目的のスタイルを得ることになります。
上の例では次のような書き方をすることになると。
Display://flexを付けてAlignItems="center",っていうのを付けたい場合のクラス名の例ですね。
クラスの付け方ですけど、divタグがあってクラスネーム="d-flex",っていうのを付けて、
その後ろにAlignItems="center",っていうクラス名を付けておくと。
で、置けば一度CSSの設定自体が書いてあるので、その呼び出しのクラス名だけは付けておけばよいという感じですね。
いやー、なんか本当に騎士感しかない感じですけど、これは。
で、これをいわゆるブートストラップとかテイルウィンドっていうのが、
まさにそのUtility Classを提供する最も人気のあるCSSフレームワークですと。
で、確かブートストラップとテイルウィンドですけど、もうダウンロードすると、
確かテイルウィンドを超えたんじゃなかったっけ?まだでしたっけ?
ついにCSSフレームワークの歴史を塗り替えるテイルウィンドがっていうお話で、ちょっと僕はワクワクしてたんですけど。
どうだった?ちょっと後でもう一回見てみます。
はい、でもそれぐらいテイルウィンドの人気というか伸び率はすごい高くてですね。
ブートストラップの画像をついに崩すのかっていう噂ですけど。
はい、戻ります。
で、これらのライブラリーっていうのは、そのユーティリティシステムに多くの設計上の努力を払っているので、
独自に開発するものではなく、どちらかを採用するのが最も合理的でした。
で、私はすでに何年もブートストラップを使用していたので、ブートストラップを一応使ってみましょう。
で、ブートストラップのユーティリティクラスっていうのはそのビルド済みのCSSファイルとして持ち込むこともできますけど、
既存のスタイリングシステムに合わせてクラスをカスタマイズする必要があったので、
ブートストラップのソースコードの該当箇所をプロジェクトにコピーしておきました。
で、数週間前から新しいコンポーネントにSASモジュールとユーティリティクラスを使っていますけど、だいぶ満足しています。
で、DXはエモーションと似ていますし、ランタイムパフォーマンスは圧倒的に優れている。
同じような開発作業ができて、ランタイムのパフォーマンスが改善できているんだったら、
それはSASモジュールで良くないっていう感じは確かになりますね。
で、余談ですけど、SASモジュールのタイプスクリプトを定義っていうのを生成するために、
タイプとSCSSモジュールっていうパッケージも存在していて、それを使っていますと。
いやー、さすがやな。やっぱ誰か作るようになって思いました。
タイプスクリプトとの親和性を保つために何かライブラリーを誰かが作ると思ったらやっぱりあったんですね。
で、このパッケージの最大の利点っていうのは、クラス名のように動作するユーティリズかっこみたいなヘルパー関数を定義できるようになったことと言っています。
これちょっと後で見てみたいですね。
なかなか便利そうなので。
はいはいはい。ではでは続いて。
続いてですね。あ、もうすぐ終わりそうですね。
はい。続いてはコンパイル時のCSS in JSについての注意点っていうところです。
今回はエモーションやスタイルドコンポーネンツのような実行時CSS in JSの、いわゆるランタイムですね。
21:04
ランタイムのCSS in JSライブラリに焦点を当てましたと。
最近コンパイル時にスタイルをプレーンなCSSに変換するCSS in JSライブラリっていうのも増えてきました。
これらはいかのようなものですと。
コンパイルドってもらうと、バニラエクストラクトってやつだと、リナリアってやつですかね。
リナリアは聞いたことないけど。
ちょっと前にバニラエクストラクトっていうのはうちの会社でもスラックでちょっと話題になって、みんなこれ良さそうじゃんって話になりました。
やっぱりパフォーマンス改善っていうところがやっぱり大きいので。
コンパイルドは僕もこっちは知らなかったですね。
バニラエクストラクトしか知らなくて、ちょっとリナリアとコンパイルドはへーって思いますね。
ちょっと見てみたいと思います。
一応この記事の中にもリンクちゃんと貼られてるんで興味ある方は後で見てみてください。
これらのライブラリっていうのは、実行時、ランタイムのCSS in JSの同様の利点をパフォーマンスのコストをかけずに提供することを謳ってますと。
謳ってる文句だけを見ると、もう完全にこっちでいいじゃん感が出ますね、そしたら。
私自身はコンパイル時のCSS in JSライブラリっていうのは使ったことがないんですけど、SASモジュールと比較するとやはり欠点があるようにはちょっと思われますと。
特にそのコンパイルドっていうライブラリを見ますと、感じていた欠点は以下の通りですね。
欠点は3つぐらいあると言ってますね。
一つ目はコンポーネントが初めてマウントされる時にもスタイルが挿入されるため、ブラウザは全てのDOMノードでスタイルを再計算しなければなりません。
この欠点はそのセクションタイトルの見にくいものでも説明しました。
この見にくいものっていう観点が結局残っていると。
これ一つで多分もう使わないっていう理由になりそうなぐらい結構痛いな、なるほど。
続いて2つ目ですけど、この例のカラープロップのような、この例っていう別のリンクが貼られていて、別のソースコードが貼ってますけど、ちょっと今回は温度化活用します。
カラープロップのような動的なスタイルっていうのはビルド時に抽出できないため、コンパイルドっていうライブラリではスタイルプロップを用いてCSS変数として値を追加します。
別名インラインスタイルだって言ってます。
インラインスタイルは多くの要素に適応するともちろん最適でないパフォーマンスを引き起こすことが知られているので、
そうですね。なのでスタイルはパフォーマンスで観点でいけば、いわゆるさっき読んでた内側と外側って意味での外側での定義の方がやっぱり良いよねって感じはするので、
インラインスタイルをでもコンパイルドってライブラリが使ってるっていうので、そこもやっぱりパフォーマンス観点としてはどうなのってお話でした。
最後3つ目ですね。3つ目はこのライブラリはまだここに示すようにリアクトツリーにボイラープレートのコンポーネントを使っていますと。
これは実行、ランタイムCSSにJSのようにリアクトDevToolsを混乱させるので、結局この本記事で書いてあった課題点が全部どっかっちゃってるっていうのがコンパイルドっていうライブラリだったそうです。
なるほどね。なんか意外と早いとか便利っていう風に謳われてますけど、実際どうなのっていうのはちゃんとやっぱり効果測定とか検証した方がいいってお話でした。
はい、というところで最後、コンクルージョン読んで終了ですね。
はい、まとめです。ランタイムCSSにJSを深く掘り下げた記事を読んでいただきありがとうございました。
24:02
どんな技術もそうですけど、ランタイムCSSには長所と短所ももちろんあります。
最終的には開発者自身がその長所と短所を見極め、自分の用途に合うかどうかっていうのを判断する必要があります。
とりあえず今回のSpotっていうサービスでは、EmotionのランタイムパフォーマンスのコストっていうのはそのDXの利点をはるかに上回ったので、捨てるっていう風な結論になったそうです。
で、SASモジュールに移ったらしいですね。
というところで、この記事は終了になります。
あとは、一応、About Spotっていうスポットサービスのご紹介とか、もし興味があったら見てみてくださいってことでした。
はい、とても興味深いというか学びもあったし、いい記事だった、本気で思いましたね。
やっぱその中の人がEmotionを捨てるっていう決断をするっていうのがめちゃめちゃ面白いですね。
ただ、この記事を読んだ感じだと、多分コミットを続けるんだろうなとちょっと思いましたけどね。
とにかくこのSpotっていうこのお仕事でやっているサービスの中ではEmotionを捨てるっていう決断をしたっていうことですけど。
なんかすごいですよね。
自分が2番目にコミットしてるっていうEmotionって全世界で使われているライブラリーなので、
それを自分から、自分の仕事では捨てるっていうのは勇気あるなぁと思いますけどね、はい。
で、じゃあ、捨てた時にどういうアプローチを取ったかっていうと、
僕ら人類が歩んできた道をもう一回歩み直したっていうところで、
やっぱり歴史は、歴史的に残っているものっていうのはやはり良いものなんだなっていうのをつくづく感じましたね。
良いものっていうのはやはり時間が教えてくれるっていうのは本当にこれに尽きると思います。
これはこういうJavaScriptじゃなくて、IT業界のそういうライブラリーもそうですし、フレームワークもそうですし、
あと本とかですね、書籍も良い書籍っていうのは必ず歴史が教えてくれるので、
時間が経ってもやっぱり名著って言われるものとか、
たくさんの人が名著って言われるものはやはり本当に名著なんだなっていう気がします。
というところで、人類の歩みできた結局SASモジュールを使うっていうのが、
僕は改めて結局そこに立ち返っていくのが興味深いですし、
その結局昔ながらの使い方ではないし、今はタイプ過ぎる人との比較じゃないですね。
親和性を上げるような、そういうサードパーティーのライブラリーもできているっていうところで、
昔と今だったら環境が違った上でもう一回SASを使うってのはどうなのっていう観点は結構面白かったと思います。
うちの会社もやっぱり基本的にはCSSにJSを使っているので、
でもパフォーマンスの観点までちゃんと負荷までやっているかっていうとちょっと怪しいところもあるので、
本当に大きいものを使ったりとか、ちゃんとスピードにシビアなお仕事とかあった時には初めてこういうのを見るんじゃないかなと思ったりします。
でもその時に、じゃあCSSにJSを捨てますかって決断ができるかっていうと、
ひっぺがして書き直さないといけないので、
納期だったりとかまた人手費コストもものすごくかかると思うので、
これはこれでやっぱり勇気いると思いますけどね。
今実際動いているものとか、スポットワードも今動いていまして、ちゃんとお金も稼げている。
そのサービスなのにエモーションひっぺがしたっていう、
決断をしたっていうのはすごいお話だなっていうのがつくづく感じました。
はい、というところで、余談ですいませんけど終わっていきたいと思いますけど、
皆さんの方でも、この記事すごくよかったのでまた改めて読んでみていただければと思います。
じゃあ今日の朝方はこちらで以上にしたいと思います。
27:00
土曜日の朝一からご参加いただいた皆さん、大変にありがとうございました。
明日はまた別の記事ですけど、ちょっと技術の記事が2、3日か後続いたので、
今度はチーム開発とかチームビルディングの話がやっぱりもう一回読みたいなって気がするので、
その辺の記事を探してみたいと思います。
では今日も土曜日ですね、ゆっくり休んでいただければ幸いです。
では終了したいと思います。お疲れ様でした。
