音声書き起こし
1. オープニング
@g4rds
こんにちは、UITの泉水です。ユーザーインターフェースと、テクノロジーを愛する開発者のためのウィークリーポッドキャストUIT INSIDE、 今週も始めていきたいと思います。今回は、皆さん、おなじみのuhyoさんとAlanさんをお呼びし、話題のSolidJSについて、 Reactなどの他のライブラリと比較しながら、お話を聞いていきたいと思います。よろしくお願いします
@uhyo_
よろしくお願いします
@AlanGDavalos
よろしくお願いします
2. 自己紹介
@g4rds
はい、では、ちょっと自分はUIT INSIDEで話すの、かなり久しぶりなので、改めて自己紹介させていただきます。えっと、 泉水と言います。今年の4月に新卒でLINEに入社して、今はLINEスキマニの開発をしています。で、一昨年 の夏、2020年の夏からインターンとアルバイトでUIT INSIDEで何回か話させていただいたことがあるのですが、
@g4rds
えっと、また改めてよろしくお願いいたします。 で、えっと、本日のゲスト。皆さん、何度もUIT INSIDEに出演していただいているので、おなじみだと思いますが、 まあのご存じない方もいらっしゃると思いますので、念のため、自己紹介お願いできますでしょうか。まずはuhyoさんお願いします
@uhyo_
はい、uhyoです。私は2019年に新卒でLINEに入社して、今までずっと金融サービスのフロントエンドを担当してきています。 ま、今回はまReactとかSolidJSの話だと思うんですけども、TypeScriptに関しても、結構技術的な発信とかを多くしております。 最近は、TypeScriptの入門書も出したので、よろしければ、手に取ってみてください、よろしくお願いします
@g4rds
よろしくお願いします僕もあの本買いましたおお、ありがとうございますすごくいい本ありがとうございますでは、続いてアランさんお願いします
@AlanGDavalos
はい、Alanです。えっと、まあ、私もあの何回か出ているんですけど、えっと、 まそうですね。今、主にあのLINEのデザインシステムの担当させていただいて、他のあの社内サービスもいくつか、あの担当者として入っております。 でも、まあの今日えっと、
@AlanGDavalos
まあ、今年の頭ぐらいにあの出した記事に、あの、SolidJSのベンチマークとかについて話していたので、あの、今日もそちらに 触れていきたいなとちょっと思っておりますよろしくお願いします
@g4rds
よろしくお願いします。はい、で、えっと、今回はSolidJSについて話していくんですけれど、 まずは、SolidJSについて、詳しく知らないリスナーの方もいらっしゃるかと思いますので、まずは僕の方から簡単に紹介しようかなと思います。 で、えっと、SolidJSはま、簡単に言うと、Reactとか、Vue.jsとかみたいなUIライブラリになります。
3. SolidJSの登場
@g4rds
で、えっと、書き方があの、かなりReactのFunction Componentに似た書き方で、 役と書いてある人だったら、お割となんか似てるなって思うかなと思ってます。 なんですけれど、SolidJSはReactと違って、バーチャルDOMを持たないっていう特徴を持っているので、バーチャルDOMがない分、早く動作するという特徴があります。
@g4rds
はい、そんな感じなのが、SolidJSの概要になります。 で、えっとuhyoさんとアランさんって、SolidJS触ってみたり、なんか使ってみたりとかしましたか。
@uhyo_
私は、あんまり本格的に使ったことはないですね、それこそ、ベンチマークやってみたときに、ちょっとSolidJSのドキュメント がチュートリアルを一通り読んで、それで書いてみたっていうそれくらいですね。
@g4rds
うん、うん、うん、うん、
@AlanGDavalos
そうですね、私もまあほぼ同程度の話で、ただ多分まuhyoさんの私もなんだろう。あの ま、これを見て、あの、なんとなくこういうフレームワークからアイデアとったなって思うところが多々あったじゃないかなと思いますね。
@g4rds
えっと、僕もちょっとSolidJS触ってみたんですけれど、まあ、割と こうReactに似てるなっていう雰囲気がありつつも。でも、実際触ってみると、意外とこう 根本的なところが違う影響で、
@g4rds
意外となんかこう気にするところが違うなっていうので、割と書き味的には結構違うなと思ったんですけど、実際その辺とかって どうですかね。
@uhyo_
そうですね、Reactとは、 Solidとはそもそもアーキテクチャーが違いますね。やっぱりだから、見た目がReactに似てるけど、あれこれReactの仲間かなと思って触ってみると、 蓋開けてみたら全然違うみたいなことが起こると思います。どっちかというと、アーキテクチャー的にはVueにかなり近いですね。
@uhyo_
あ、細かいapiの違いを除いたら、理由から仮想DOMを引いたら、SolidJSになるって言っても、およそ間違いじゃないかなと思います。
@g4rds
そうなんですね、なるほど、なるほど、
@AlanGDavalos
そうですね、あの、私もuhyoさんとほぼ同意見で、あの、なんて言えばいいんですかね。なんか、 あのSolidJSに存在するあのForとか、Indexとか。あの、
@g4rds
はい、
@AlanGDavalos
あの、そういったえと要素が結構そのなんだろう。Vueのv-ifとか、v-forとかにあのすごい近いような感じもしていて、 あの、多分そこも含めて結構なんか、あの、Vue.jsの書き方に近いところがあったりするのと ま強いて言えば、なんか
@AlanGDavalos
ま、Vueと同じProxy系のあの内部を持ってはいるものの、なんか、DOMとのとの関係性はま、どちらかといえば、なんかLitとか、なんか、 そっち系のあのフレームワークに近いんじゃないかなって思ってて、で、Reactに似てるのはほんとになんかHooksのapiのあのあ、 なんだろう。まあ、作り方とかの方じゃないかなってちょっと思いました。
@g4rds
確かに
@g4rds
言われてみれば、Reactのファンクションコンポネントってこう。関数がJSXを返すみたいな 感じの見た目をしてますけど、Solidともそれっぽい見た目はしているんですけど、実際はこうJSXの中で、あの、 えっと、まReactのステートにあたるのがSolidだとシグナルって呼ばれてるんですけど、シグナルとか、propsのアクセスがあったら、そこがこうテンプレートに
@g4rds
埋め込まれていく感じのイメージがありましたね。確かに、それで言うと、Vue.jsとかに近いなと確かに思いました。
@uhyo_
そうですね、なので、Solidの関数コンポーネントは、関数の中のJSX以外の部分がVueでいうscript setupで、 JSXのところが、あの、普通のテンプレートのところだって思ったら、大体合ってると思います。
@g4rds
なるほど、なるほどですね、確かに確かに結構 それって割となんか関数っぽいけど、実は関数じゃないなっていうのが結構いいところではあるのか、 ま、なんか、こうちょっと混乱するところではあるので、そこの認識をちゃんと理解しておくと、結構もっと使いこなせそうな感じですね。
@uhyo_
でも、なんか、シングルファイル、コンポーネントとかそういうのは嫌で、JSXを取り込みたいって思ったら、多分ああいう形になるのかなっていう印象ですね。
@g4rds
なるほどですね、
@AlanGDavalos
確かにそうですね、
@AlanGDavalos
ほんとになんか色々なフレームワークのやり方を見て、あ、こういうところが好きだなって、あの色々なんかピックアップして、自分のものにしたみたいな。 あの感じが結構しますね。
@g4rds
はいはいはいはい、なるほどですね、確かに僕は全然なんかいろんなやつに触れてこなかったんで、結構新鮮なんですけれど、 意外といろんなライブラリからの要素をこう引っ張ってきてる感じなんですね。そうですね、
@uhyo_
あ、なんかReact要素はまさにcreateSignalのAPIがちょっとuseStateっぽいとか、多分そういうところかなと思いま。
@AlanGDavalos
そうですね、ほんとになんか、useEffectとか、createSignalとか、なんかそこらへんがすごいReactっぽいですね。
@g4rds
確かに確か
@g4rds
そうですね、割とReactのhooksって結構お、これはめちゃめちゃなんか求めていたものだな感があったので、 そこを引っ張ってくるの、かなり 好きだなって思ってます。で、えっと、ちょっと触ってて思ったのがおjsxの中で、type narrowingが全然
@g4rds
なんかあまり効かないなっていうのがあって、こう。えっと、Solidだと、えっと ま。例えば、undefinedable、undefined、もしくは何ちゃかのデータみたいな。えっと、シグナル を表示する時に、えっと、例えばundefinedじゃない場合、このコンポーネントを表示するみたいなことを書きたいときに、Showとか、
@g4rds
そういったコンポーネントを使うと思うんですけれど、そのReactだと、そこで、条件式で判断した後は、type narrowingが 効くと思うんですけれど、Solidだと、あのま、そもそもJSの式じゃないんで、そこがうまく聞かないっていうので、Showとかのコンポーネントの内側では、こうnon nullにアサーションするとか。
@g4rds
あのShowのチルドレンにこう関数を受け取って、その引数のところで、えっと、 narrowingした結果が渡されるみたいな感じの書き方が、公式のドキュメントで、えっと、紹介されているんですけれど、 この後者だと、ちょっとパフォーマンスが悪くなりますよ。みたいなことも書いてあるんですよね、この辺って、
@g4rds
なんかこのShowの内側をが、えっと、常にこのwhenの内側 の条件がfalseからtrueになった時だけにこう書き変わる。その内側の部分のこの ネームのアクセス部分だけが書き変わるのが本来のあれだと思うんですけれど、そうじゃなくて、内側全体がリレンダリングされるというか、
@g4rds
を実DOMに変更が入るみたいな、そうみたいな感じの記述があるんですよね。 ので、公式としては、どんなnon nullアサーションとかを使いという認識なんですかね。
@uhyo_
やっぱり、自分としては、non nullアサーションとか使ってほしくないな、という風に思ってまして。
@g4rds
そうですよね、
@uhyo_
だから、このShowのcallback関数にそのnon nullになった方の値が返ってくるっていうのは、個人的には割と まSolidの制限の中では筋がいいなという風には思ってたんですよ。 だから、関数のコールバックで、肩から胸が消えてるってのは、割と他の言語でもある。アプローチで、
@uhyo_
例えば、Rustだとオプション型になんかマップっていうメソッドが生えていて、 mapに渡した関数から、まあ、そのオプションに値が入ってないっていう、そういう可能性が消えるんですよね。
@uhyo_
なんか、そういう風なそうなんですよ、なんか、そういうなんて言うんでしょうね。説明は難しいんですけど、こうか、論理的な良さって言うんですかね。 というのが、このコールバックのアプローチからは感じていたんですが。 なるほど、それではパフォーマンス悪くて、あんま推奨されてないってなると、とてもちょっと残念ですね。うん、
@g4rds
うん、そうですよね、なんかでもこの辺はどうしようもないのかなって思ってはいるんですよね。
@uhyo_
そうですね、ま、JSXで書かれてるから、他のVueとかSvelteみたいに、エディタの拡張に頼らなくても、TypeScriptのフルパワーが出せるっていうとこは、Solidの良いとこだとは思うんですけど、 え、良いとこだと思ってたんですけどね。
@g4rds
そうですね、もっと改善の余地がある感じがありますね。割とGitHubのSolidJSのリポジトリ見に行ったら、 あのタイプスクリプト関連の議論も割とされているなんて、継続的にされていたので、ちょっと この辺、もっと改善されると嬉しいなと触ってて思います。
@uhyo_
これ、なんか、Showとかを使って分けさせなきゃいけないっていうのもまSolidのまあ、あんまり良くないと思うんですけど、特徴な気はしていますね。 Solidって、jsxがなんかリアクティブのマーカーになっていて、jsxの中に書いたものしか、リアクティブに反応しないんですよ。
@g4rds
ああ、
@uhyo_
なるほど、そうだからそうなんですよ。だから、分岐でjsxの式を出し分けるっていう行動を書くと、その分岐っていうものがjsxの外の見なされるから、なんか、リアクティブにならないみたいな。あ、 なるほど、それがわざわざそのShhowとか、そういうコンポーネントを使って分岐させてる理由だと理解してます。
@g4rds
jsxにしないといけないってことですね。このあの波かっこ curly parenthesesで区切っちゃうと、それがまた別のJSXみたいな感じになって、そこ自体がもう別のリアクティブな こうツリーになるというか、それ自体がもうまた毎回毎回書き変わるみたいなイメージなんですかね。
@uhyo_
あんまりその具体的なとこまでは知らないですけど、とにかくそうです。多分そうだと思います。だから、ほんとにそのなんかSignalの呼び出しがjsxの外に書かれていると、リアクティブにならないんですけど、 それをなんかただ何もない。フラグメントで囲むだけで、リアクティブに変わったりするんです。
@g4rds
おおあ、そうなんです
@uhyo_
はい
@g4rds
はいはいはい、
@g4rds
なるほど、なんかその辺を理解すると、もっとSolidJSかなり使いこなせるなって、うん、うん、うん、思いました。これ
@uhyo_
は、twitterで聞いた見た意見で、私もそうだなって思ったのは、そのVueとか、Svelteとかだと、テンプレートを絶対1か所にまとめるじゃないですか。
@g4rds
はい、
@uhyo_
Solidだと、そのjsxっていう単位がリアリアクティブになるから。なんか、jsxを1つのファイルの中になんかチラ ばらせて書くというか、いろんなとこに書いても、それぞれがちゃんとリアクティブになって、組み合わせることができる。
@g4rds
え、それすごいですね、
@uhyo_
それは、Solidの利点なんじゃないっていう風に言ってる人もいて、それは結構確かにっていう風に思いました。
@g4rds
え、え、あ、じゃあ全然なんかコンポーネントにこう細かく分けていくというよりも、 もう1つのコンポーネントの中にこう軽いコンポーネントだったら、ぽいって、jsxを追加してあげるだけでも、十分良くなるみたいな。
@uhyo_
そうですね、自分で試したことはないんですけど、その可能性はとてもあると思います。
@g4rds
そこは、また、なんかReactにない良さかなと思いました。それでと、結構周辺ライブラリー はまだまだそんなに出てないよねっていうところは。でも、Reactのこうモダンなapi Suspenseとか、useTransitionとかも。 すでにSolidの標準に入っちゃってて、この辺とかuhyoさん触ってます。
@uhyo_
そうですね、ま、軽くさわって見て、ああ、サスペンスはReactと同じだねってなりました。 でも、Vueにも確かもうSuspenseがあったと思うので、結構これからのスタンダードになるかもな、という風に思ってます。
@g4rds
うん、うん、うん、そうなんですね、もう他にもなんかReactでいうreact queryとか、 あとはrecoilみたいなデータフェッチングとか、グローバルなステート管理、ライブラリとかも。もう既にsolid-jsライブラリの中に入ってたんで、 結構まその辺ないからみたいな話にはならないなって思いましたね。結構すぐに使い始められるなって
@AlanGDavalos
思います。そうですね、あの、Solidのウェブサイトにも載ってるけど、なんかあのReactは あくまでなんか自分はライブリでやって、フレームワークじゃないってまだ言い張るところはあるんですか。 ま、Solidはそうではなくて、なんかま、ステートの部分は結構オピニオンが強いから、こういう風になんか提供してますよ。みたいな、あの文章が
@AlanGDavalos
あの書いてありましたので。まあ、そういうところはもうほんとにまどちらかといえば、ほんとになんかVueっぽいところの1つで。あの、 まあ、とりあえずあの、そういうベースなところはちゃんと入ってて、あ、なんかもうちょっとなんかあったんすっていうか、なんか具体的な。あの 機能とかはま、あのまライブラリーとかで、あの、提供する方がいいというところかなと思いますね。
@g4rds
なるほどですね、ありがとうございます。ちょっと、 あのSolidJSについて、かなり理解進んだかなと思うんですけれど、こuhyoさんが先月出された Reactに有利なベンチマークを作ってみたとか、React脳によるUIライブラリー書きやすさランキングとかのこれQiitaの記事読んだんですけれど、
4. @uhyo_ のベンチマークについて
@g4rds
あ、これあのまだもし読んでないリスナーの方いらっしゃいましたら、是非Shownoteに書いてあるので、開きながら聞いていただければなと思うんですけれど、そこで、SolidJSも、あのベンチマークとかのランキングに登場したと思うんですけれど、 あのSolidJS公式は結構早いっていうのを歌ってるんですけれど、実際その辺ってどうなんでしょうか。
@uhyo_
あ、そうですね、あのベンチマークはReactで有利なって書いてある通りに、なんかReactだけ、実は違う土俵で戦ってたんですよね。 はいはいはいはい、このベンチマークって、なんか、メインスレッドが100パーセント使われてる時に、どれだけユーザーの入力に素早く反応できますか。みたいなテストになっていて、 Reactはすごいスケジューリングを頑張っているから、メインスレッドが100パーセントを占領されていても、ユーザーがインプットで割り込んだら、素早く反応できるんですけど。
@uhyo_
他はそういうスケジューリングをしてないから、1回レンダリング始めちゃったら、終わるまで、ユーザーの入力に反応できないっていうことなんです。
@g4rds
なるほど、
@uhyo_
そうそういう点で、実はReactに有利なベンチマークになってたんですね、あれは
@g4rds
なるほど、レンダリングに時間がかかるケースだと、Reactが有利、総じて有利っていう感じなんですかね。
@uhyo_
まあ、ほんとに100パーセントのメインスレッドを食っちゃうような、ほんとに高い負荷にならないと、多分違いは出ないんですが。
@AlanGDavalos
そうですね、ま、uhyoさんのベンチマークは、そもそもなんかあの表示してるDOMのあのノードの数があのすごいことになっていたので、まあ、さすがにあの普通のなんか、 あのプロダクションのアプリだと、まあ、あの バーチャルのリストをかけたり、なんなりで、あの、そもそもそれを制限することから始めることはあると思うんですけど、
@g4rds
確かにそうですね。4000個近くのDOMがばっとあって、それが一気にこうリライトされる感じなんですかね。
@uhyo_
そうですね、ただ、確かにこのベンチマークは割と非現実的な設定ではありましたけど、でも、意外と本質をついてるところはあるんですよね。 このもりか、これでReactが有利になるためには、React18で導入されたuseTransitionを噛ませてあげないといけないんですよ。はい、つまり、このReactが有利になるスケジューリングっていうのは、まあ、React18で入ったことになるんですよね。
@uhyo_
だから、React18って言われると最近なんですけど、そういう時にこういう風にま、そういうようなケースも想定した。ま、ある種のパフォーマンスの改善とか、そういうのをReactは入れてきたから、まあ、多分Reactがfacebookとかの中で使われてる中で、 ま。ここまで極端じゃなくても、ある程度コンポーネントツリーがでかくなって、これくらいの制御が必要な場面ってのは、多分まReactを作ってる
@uhyo_
側では感じてるんじゃないかな、という風には思います。
@g4rds
なるほど、こうなんか windowingだけじゃ解決できない。もう両方2つの剣を使って、それに対抗していこうっていう 感じの一種の1つのやり方組み合わせられるやり方なんですね。
@uhyo_
うん、うん、まあそうコンポーネントツリーがでかいって、データのリストがたくさんあるだけじゃなくて、そもそもページにコンポーネントがたくさん配置されてるとか、 コンポーネントツリーがでかいっていうことがありますので。うん、うんまそのインフィニットスクロールとか、バーチャルスクロールが適用できる場面っていうのは、まあ、データがたくさんある場合に限られてるんですよね。 ま、Reactのアプローチがまより、どんなコンポーネントツリーにも適用できる一般的なものとして作られたのかな、という風に思っています。
@g4rds
そのuseTransitionの話で言うと、SolidJSにもuseTransitionがあって、こうゆうさんの このベンチマークのリポジトリ見に行くと、SolidJSの例でもuseTransition使っている ですけれど、はいも、ベンチマークの結果的には、SolidJSはなんか全然速度上がっていないなって思うんですけれど、
@g4rds
これってなんでなんだろうって思ったんですけれど、
@uhyo_
なんかSolidJSはなんかなんとなく、Reactのコードになるべく近づけるためだけに、useTransitionを使ったんですけど、あれは全く意味をなしてないです。
@g4rds
あ、そうなんですか、はい、
@uhyo_
なんかReactとSolidJSでは、同じuseTransitionってAPIでも微妙にやってることというか、意味が違うんですよ。
@g4rds
あ、そうなんですね
@uhyo_
あ、SolidJSはuseTransitionの中で、ステート、シグナルか、が変更されて、それによりSuspenseが発動した場合に、そのサスペンドが完了するまでは、前のステートの表示を出し続けるっていう機能として多分
@uhyo_
useTransitionが定義されています。なるほど、で、Reactもそうなんですけど、Reactでは、それはuseTransitionの一側面でしかなくて、 Reactの原理においては、useTransitionの意味は、ステート更新の優先度を低くするほどなんですね。 Suspenseの挙動っていうのは、そのまあある種結果として現れてるものですから。まあ、えっと、SolidJSのuseTransition、は
@uhyo_
なんでしょ、ReactのuseTransitionの一側面だけをまあ切り取ってAPI化したもの だから、今回のベンチマークでは、特にSolidJSにおけるuseTransitionは、意味をなしていなかったんです。
@g4rds
なるほどですね、結局、こう全部のDOMを一括で書き換えようとしちゃって、そこのオーバーヘッドが全然useTransitionでは、解決できてないっていう感じなんですね。
@uhyo_
そうですね。SolidJSにおいては、そういう用途のAPIではないってことですね。なるほどですね、あ
@g4rds
を、なんかサスペンドするケースっていうのは、例えば外部にリクエストを飛ばすとか、その辺が絡まないといけないっていう感じなんですかね。
@uhyo_
あ、そうですね、SolidJSのuseTransitionは、パフォーマンスがどうのというよりは、ほんとに、ま、ある種の機能だと見た方がいいと思います。 なるほど、サスペンスした時に、前の画面が出続けるっていう機能ですね。
@g4rds
ああ、なるほどですね、例えば、ルーティングするとか。
@AlanGDavalos
そうですね、あの、サンプルに使われているケースは多分まさにそれで、あのま、例えばなんかタブの方であの 使われていて、まあ、タブのアイテム自体がえっと、まチュートリアルの方ですね。あのチュートリアルの方にあの 使われていて、あのまタブを変わらないと、あの、新しいコンポーネントがロードされないなどというケースで。
@AlanGDavalos
まあ、なんかその新しいあのコンポーネントがロードしない限り見せないという。ま、あの先ほどuhyoさんが説明してたパターンをま あのそういうふうに見せてるんですけど、ま、まさにあのま、そういうユースケースを想定したあの機能になってるんじゃないかなと思います。
@g4rds
なるほど、そもそも全然違うものであるという感じなんですかね。そうですね、ありがとうございます。 確かにそれもうひとつこう、今のはベンチマークの話だったんですけど、こうもう1つの React脳によるUIライブラリ書きやすさランキングの記事の方なんですけれど、この記事では、なんとSolidJSは
@g4rds
第4位ということで、この辺ってなんかなんでなんだろうっていうのはありますかね。
@uhyo_
そうですね、やっぱり4位って、まあ、正直に言ってしまうと、そんなに好きじゃないっていう意味なんですけど、やっぱりReact脳だからっていうのもあって、Reactと似た見た目だけど、なんかやってることが全然違うというのが、あんまり気に入らないですね。特に、 JSXの扱い方が、やっぱりReactとは根本的に異なるんですよ。
@g4rds
そう、そこめちゃめちゃ意外でした。
@uhyo_
そうですね、Reactは本当にコンポーネントツリーのノードを生成するっていうのが、JSXの役割でまある意味ただの式であって、それこそ JSXを使わなくても最悪書けるようなのだと思うんですけど。SolidJSはさっきもちょっと話しましたけど、なんか、 リアクティブネスのマーカーとして、jsxを使ってるところがあって、
@uhyo_
なので、なんかもうJavaScriptというより、ある種のDSLだなみたいな感じ、そういう印象を受けています。SolidJSのjsxの使い方は
@uhyo_
なので、Signalを読むときとかは、jsxの中に書かれていた関数呼び出しを、あ、ちょっとリファクタリングしようと思って、jsxの外に出して、変数に入れたりしただけでも、挙動が変わっちゃうんですね。jsxの外は、リアクティブじゃないんで。
@uhyo_
普通になんか、jsxの外に移しちゃうと、Vueのテンプレートからセットアップの方に計算が映っちゃうみたいな感じで、 意味が全然変わっちゃうんですよね。うん、うん、うん、そういうので、なんかちょっとJavaScriptから離れすぎてるなっていう印象ですね。 と自分は思っていて、それでうん、あんま好きじゃないなっていうのは思いました。
@g4rds
確かにそうですね、なんか、暗黙の了解というか、その辺の理解がないと、
@AlanGDavalos
要はそのなんて言えばいいんですかね。あの、ほんとにSolidJSとReactが似てるのって、あの、ま、あのHooksのAPIとJSXを使ってること しかなくて。あの、考え方自体が根本的から違うので、そのReactの風にかけると思いきや
@AlanGDavalos
書こうとしたら、おそらく無理で、あのま、ちゃんとSolidの概念っていうか、理念を あの理解した上で書かないと、あのうまくいかないという風に思いますね。
@g4rds
なるほどです。こうなんか、軽い軽いコードを書きたいぞって感じで、軽い気持ちでこうSolidを採用する。 なんか、preactを採用するノリでSolidを採用するのはちょっと違うよって感じですかね。ちゃんと、別のフレームワークとして認識しないと、 かなり、おや？って感じになっちゃうって感じですかね。
@uhyo_
そうですね、まあ、ファンも多いので、悪いライブラリではないと思うんですけど、React脳のまま行くと、ちょっと危険かなって思います。
@g4rds
うん、うん、確かになんか結構僕も書いてて、すごいSolidJSの知識をこうどん、どんどんどん積み重ねていって書いていく。
@g4rds
なんか
@g4rds
脳の動き方をしていたんで。なるほど、確かに全然Reactとは違うなって思いましたね。これはこれで、確かにProxyを使って、VirtualDOMを消すんであれば、うん、確かにこうなるなっていうのは理解するんで、うん、うん、うん、なるほどですね。 あとここのランキングで言うと、SolidJSは4位だけど、2位にSvelteがいるというのがちょっと意外だったんですけど、この辺ってどうなんですかね。
@uhyo_
なるほど、あ2位のSvelteはあれですね、なんか、ロジックが書きやすいというか、 なんかSvelteはかなり、なんでしょう、コンパイラーが、静的解析しやすいように作られてる気がするんですよね。 だから、そのリアクティブのシステムに、多分、Proxyにそんなに頼っていなくて、
@g4rds
あ、そうなんですか、
@uhyo_
確か、Svelteのドキュメントを見た時に、なんか、代入がそのアップデートのトリガーになってますよ。っていう風に書かれていました。 どの処理が行われた時に、そのどの変数が変化したかっていうのをトラックするのが、ランタイムじゃなくて、多分コンパイルタイムに行われています。代入分を見つけて、ああ、この変数はここで変わるんだなっていう風に、わかるはずなので。
@g4rds
この$:が先頭に入ってる文は、そこがコンパイルされて、 そこの文が実行されたら、えー、リレンダリングが走るみたいな定義になってるって感じなんですか。
@uhyo_
そうですね、なんか、そのリレンダリングのトリガーも、なんか、じゃあ、リアクティブな変化を発生させたトリガーも、 変化が発生した時に、どこにそれが波及するのかっていうのは、そこのdependencyもかなり そのコンパイルタイムに静的に解析できるようにしているっていうのは、個人的にSvelteのかなり好きな点ですね。
@g4rds
あ、それはいいですね。
@uhyo_
はい、さっきのベンチマークの記事でSolidJSよりも、Svelteがかなりいい成績を出してたと思うんですよ。 ま、SvelteもSolidJSも、そこはほんとにレンダリングの速さだけで戦ってて、それだけの差がついてるっていうことなんですけど、多分、 自分の想像では、Svelteの方がコンパイルタイムに最適化できる内容が、このベンチマークで多かったんじゃないかな。
@uhyo_
ランタイムにやんなきゃいけない、タスクが少なかったから、それだけSvelteが有利になったんじゃないかなと思っています。
@g4rds
おお、なるほどです。
@uhyo_
はい、SolidJSはProxy使ってるから、要するにランタイムで頑張ってるんですね。Vueとかもそうなんですけど、 Svelteはそれよりもコンパイルタイムにやってる解析の内容が多いんだと思います。
@AlanGDavalos
そうですね、ただ、その分、まあ、アプリケーションが複雑化することによって、あの、そもそもSvelteはなんかあの、 はい、吐いてる時にあのまあの結果を出してる時に、あのライブラリー自体のコンポーネントのコードが少ない分、 あの、結構ま、自分のコードがなんかコンパイルされた後に、あのすごい大きくなるので、
@AlanGDavalos
あの、ある程度大きめのアプリケーションになると、結構なんか、サイズがあのSvelteの方が大きくなったりすることは、あの、見られますので、Svelteはある程度小さめのアプリケーションまでだったら、他より断然有利だけど、 それが少し経つと、もうちょっと、あの、その有利がなくなりますね。
@g4rds
あ、そうなんですね
@uhyo_
そうですね、確かに、ここまでランタイムのパフォーマンスの話ばっかりしていましたけど、もう1つフロントエンドでは、 バンドルサイズのそっちの方面でのパフォーマンスっていうのが、結構重要なポイントですね。
@g4rds
確かにそうですね、バンドルサイズで言うと、アランさんは、このLINEエンジニアリングブログの記事、 2022年におけるフロントエンド開発のベースラインという記事。今年の初めに出ましたけれど、あの、その話で あのバンドルサイズがこうパフォーマンスに与える影響について話されていたと思うんですけれど、
5. パフォーマンス観点でのUIフレームワーク選定
@g4rds
確かにバンドルサイズという面で言うと、こうコンパイルが走って、自分が書いたコードよりも、そこの部分が 増えるっていうタイプだと、結構バンドルサイズ大きくなっちゃうイメージなんですかね。
@AlanGDavalos
そうですね、あの、ほんとにその通りでま、なんて言えばいいんですかね。ま、これを見るには、えっと、ちょうどあの記事にある、えっと、30のコンポーネントを比べる、あのバンドルサイズを比べる、あのグラフがあると思うんですけど、なんかあそこに結構、ま、ある意味、なんか、アプリをあの作る想定で、なんかま、それぐらいのコンポーネントは絶対あるよっていう風にま見て取れるので。はい、あの、
@AlanGDavalos
やはり、ま、ライブラリー自体のサイズと、まあ、あの最終的にはコンポーネントのサイズでま、結構あの結果は変わったりするんですけど、 ま、例えば、なんかReactだとま、自分が書いてるコードが凄い少ないけど、ま、ライブラリ自体があのま、バーチャルDOMの実装とかの影響ですごい大きいので、 あの、結構跳ね上がってしまいますけど、逆に、ま、さきほど話していたSvelteは、ほとんどコンパイルだから、ほとんど全部自分のコードで、
@AlanGDavalos
あのライブラリ自体のコードは1キロとか、なんかそういうぐらいすごい小さめで
@AlanGDavalos
Solidとかだと、まあ、あの3キロバイトがライブラリで、まあ、あのこの場合はまあ、えっと、11キロバイトがあのコンポーネントのサイズになってたんですけど、 まあ、もう少しバランスがある方なので。なので、あの結構まやはりなんかライブラリー自体があの、ま、この場合、結構SolidJSがバーチャルDOMに依存していない部分もあって、
@AlanGDavalos
あの、まあなんかそういうDOMがやってることを、あのライブラリがやらなきゃいけないというわけではないので、 そもそも、なんか、ライブラリとしてのコードがすごい少ないっていうところがあるので、あのま、結果的にサイズがすごい、あの、まあ、小さめの方の部類になるんですよね。まあ、それこそあのSvelteより若干小さくて、あのLitとかPreactと同等ぐらいのサイズになりますね。
@g4rds
結構違うんですね、こうこうなんか、ライブラリーサイズと、ユーザーコードサイズで、こうグラフを見てみると、かなり面白い結果になりますね。
@uhyo_
確かにReactはこれライブラリがでかいけど、コンポーネントのユーザーコードのサイズは、一応1番小さくなってるんですね、これは結構意外でした。
@AlanGDavalos
そうですね、
@AlanGDavalos
あの、Litとほぼ同様で、あの9キロバイトぐらいですね。この場合は、
@uhyo_
ライブラリのサイズって、アプリケーションがどれだけでかくなっても変わらないけど、コンポーネントのユーザーコードのサイズは、 アプリケーションがでかくなると、どんどん比例して増えていくと思うんですよね。はいはい、そうですよね。そうなると、 そういう時になんでしょう。そのライブラリが小さい部分のペナルティがだんだん減っていくのかな、という風に思いました。
@g4rds
確かに、それで言うとSvelteは、ちょっと不利なんですか。このユーザーコードが大きくなってしまうというのは。
@uhyo_
そうです。そうです
@AlanGDavalos
ほんとに、あの、ま、Svelteは、なんかすごい大きなアプリケーションになると、まあ、逆になんかこういったバンドルサイズで、あの、 ま、あのちょっと大きくなってしまうということはあるんですよね。 ま、それ以外のライブラリは大体なんか、あの、自分のユーザーのコードのサイズがあんまり変わらないところがあるので、
@AlanGDavalos
まあそこはそこまで問題になることはないんですけど、多分ほんとになんかSvelteはその点ですごい特殊なケースなんですよね、 コンパイルベースなんで。
@uhyo_
確かに、Reactの1.6倍のスピードで、バンドルサイズは成長していきますね。アプリケーションの成長とともに、
@g4rds
それは確かになかなかにまずそうなこれ、結構Reactで何十メガみたいなバンドルサイズになってるプロジェクトよく見るんすけど、それが さらにもっと増えちゃうみたいな感じなんですか。
@AlanGDavalos
そうですね、まあ、なりかねないんですよね、だから、まあ、あの、そういうところはちょっと注意が必要ですね。
@g4rds
あ、なるほどです
@AlanGDavalos
で、あと、あのその記事で紹介していたベンチマークのもう1つなんですけど、あの、これは結構なんか。まあ、あの Solidのまあ良さとかがはっきり、あの、見えるところの1つなんですけど、 ま、それの元ネタである、えっとま、jsのフレームワークのベンチマークで、
@AlanGDavalos
ま、色々な、なんかでっかいリストの、あの、ま、順番をあの入れ替えたり、なんか削除したり、なんか色々なあの動作をしながら確認している、えっと、まあ、ベンチマークがあるんですけど、あの、そこでなんだろう。1番なんか、 あの、SolidとReactとかとの違いが1番よく見えるのは、あのメモリーの使い方とかの方なんですよね。
@g4rds
ああ、これ全然違いますね
@g4rds
Solidは1.4、Reactだと2.6とか言っちゃうんですね。
@AlanGDavalos
そうですね、で、しかもなんか、あの、Reactだとまあ使ってるｍえっと、ステートライブラリによっては違ってて、なんかReduxとかだとすごい あの大きくなってしまうんですけど、
@AlanGDavalos
純粋にHooksを使うとま1番マシな方で、ただ、それでもなんか結構あのメモリーを使っていて。ま、これも多分先ほどと同じ、なんかバーチャルDOMがあるかないかの違いが、多分1番大きくて。ま、やはり、なんか純粋なDOMのツリーを、あのあえて、なんかJavaScriptで、ま、再度似たような構造を持ってることで、2重になってしまうんですよね。なんか、DOMのノードの数だけ。
@AlanGDavalos
だから、なんかそういう点だと、まあ、あのSolidとかLitとか、 あのSvelteみたいに、まあ、バーチャルDOMに依存しない方のフレームワークは、結構メモリーのあの使ってるところはほとんど同じで。ただまあReactとか、あの、まあ、Preactもここでも結構まあんまり良くはないし、Vueもそうなんですよね。なんか、バーチャルDOMも使ってるところで、1番あの痛いところはほんとにメモリーの使い方ですね。
@g4rds
ああ、なんか意外とあんまり。これはメモリーどんくらい使ってるのかって普段見ないですけれど、意外と実際見てみると、めちゃめちゃ 使っちゃってるっていうのはなるほど、そうなんですね、メモリをいっぱい食って、ちょっとでもパフォーマンスを上げていこうみたいな感じの 設計になってるんですかね。
@AlanGDavalos
そうですね、ただまあ純粋になんかあのま、その分なんかえー、ま、実際になんか、ま、速度であの測るタイミングでも、まあよくはなってないので、ベンチマークもそうなんですけど、その、まあ、すごいあの特別なケースで、ま、実際になんか、あのリアルのアプリで必ずしもなんか同じような結果になるというわけではないんですけど、
@AlanGDavalos
まあ、こういう風になんかあのバーチャルDOMで、 あの結構、ま、なんて言えばいいんですかね。なんか、パフォーマンスが元々ま、これで良くなるっていう風に、あの、考えたんですけど、 特定のユースケースではそうなんですけど、あのほとんどの場合だと、ま、結構あの大きな負担になってしまうっていうこともあるので。
@AlanGDavalos
まあ、なんか最近あのVueもなんかバーチャルDOMなくすような動きをあの多々見れるので、バーチャルDOMから 外そうという風な動きが結構色々なところにあの続いてます。
@g4rds
あ、そうなんですね、それって、Reactとかにもそういう動きってあるんですかね。バーチャルDOMをなくす動きって。
@uhyo_
いや、Reactはなくさないと思います。でも、Reactってスケジューリングに力入れてるんですけど、そのスケジューリングって、バーチャルDOMがないとできないんですよ。
@g4rds
あ、そういうことなんですね、そもそも、じゃあ、さっきあのおっしゃってた途中でレンダリングやめるとかって、他のバーチャルDOMがないライブラリだと、そもそも実装が難しいって感じなんですね。
@uhyo_
そうですね、今DOMを一旦書き替え始めたら、最後まで完成しないで、途中でやめちゃったら、なんか変な状態がユーザーに見えちゃうので。まあ、それはダメなんですよね。だから途中でやめようとも思ったら、 あ、頑張ってめちゃくちゃ頑張ってロールバックするか、1回最後までやり切っちゃってから、もう1回直すか、どっちかしかなくて。
@uhyo_
だからReactはそうバーチャルDOMツリーで遊んでる間は、Reactはいつでも、まあ、やめ放題なんですよね。まだ実際のDOMに入ってないから。それが、まあReactのスケジューリングの本質なので。だから、Reactは完全に バーチャルDOMと一緒にやっていく方向に舵を切ってるんだと思います。
@g4rds
なるほどですね、確かuhyoさんのベンチマークみたいなこう、単純なコンポーネントの羅列だったら、まあ途中でやめても、まあ最悪 いいかもしれないですけど、実際はそうではないですもんね。なるほどですね。Reactは、やっぱり サーバーコンポーネントとか、そっちの方面でも頑張ってるんで。
@AlanGDavalos
ただ、まあ、実際になんかあのReactも、あの ま、そのままがいいと、あの言ってるわけではなくて、あの、実際になんか今ちょうどまあ長い間なんか結構。まあ、 バーチャルDOMの扱い方とかについてで、あのまイベントシステムを改めるとか、なんか色々なあの工夫を、
@AlanGDavalos
まあ、結構長い間なんか17に入れるか、18に入れるか、19に入れるか。まあ、色々。あの長い間やってるんですけど、 ま、今ちょうどなんか19にやりたいなっていう風になってるっぽいので、おあの、バーチャルDOMのままではあるんですけど、なんか、このメモリーの使い方とかま、サイズが、ま、若干減らせるといいな、という風に思いますね。
@g4rds
おお、なんかそれめちゃめちゃ期待ですね。結構その辺書き換えちゃうと、今の設計とは、ちょっとブレーキングが入っちゃうから ま、今の今今で入れられるという話ではないっていう感じなんですかね。
@AlanGDavalos
そうですね。
@AlanGDavalos
ちょうどあのま、今えっと、あの、多分ショーノートにあの追加するリンクの1つになると思うんですけど、 あの、まReactがまあ、えっと、まあ18ではなんかBreaking Changeはしなかったものの、なんかイベントシステムとかのあのか、まあ、あの削除するとか。なんか色々、あの、ま、内部を変えてくるんじゃないかっていう話が
@AlanGDavalos
ありました。
@g4rds
おお、これは知らなかった、めちゃめちゃ気になる。これは続報がめちゃめちゃ気になりますね。 なんか、もうサーバーとの連携に振り切っていくのかなって思っていました。そもそもそうですもんね、サーバーコンポーネント来たとしても、
@g4rds
特殊な文字列、あいつをパースするところがないといけないから、結局バンドルは結構でかくなっちゃうのかなって思ってたんで、そういうことなんです、 ありがとうございます。最後にですね、ここまでの内容を踏まえてですね。ちょっとお二人に、ちょっと個人的に聞きたいんですけれど、 今、新しいプロジェクトでこうなんか、UIフレームワークを導入するとすると、
@g4rds
今、どのフレームワークを選びたいとかってあったりしますか。
@uhyo_
私はそれ5秒でReactって答えますよ
@g4rds
意外と5秒はかかる。やっぱそうですよね、やっぱuhyoさんは、やっぱりReactなんですね。アランさんって、結構 普段僕なんか、どんなフレームワークを使われてるのか、イメージがないんですけれど、
@AlanGDavalos
そうですね、私はあのまLitを使うことが多いので。まあ、あの、自分だったらLitにするんですけど、ま、正直なところ、あの、ま、先ほどのベンチマークとかで、あの、結構特にバンドルであの、似たような結果を出していたものが何個かあったと思うんですけど、 ま、個人的にはなんかあのそのなんだろう、15キロバイト前後
@AlanGDavalos
の辺りにあるものだったら、ほぼ何でも良くて、まあ、 なんかあそこらへんだったら、ある程度のパフォーマンスのベースラインを保てるので。 まあ、それだったらあの個人的に依存はないんですけど、ほんとに自分だけの判断だったら、Litを使いますね。
@g4rds
15キロバイト前後で言うと、Lit、Solid、Preact、Stencilまで入りますかね。
@AlanGDavalos
Svelteも、まあ入れてもいいと思います一応
@g4rds
ありがとうございます、ちょっとめちゃめちゃなんか、結局どうなん、ていうところが聞きたかったので、聞けて、すごく嬉しいです、ありがとうございました。
6. クロージング
@g4rds
はい、今回はSolidJSについてや、それを踏まえたUIフレームワークの評価について、uhyoさんとアランさんに聞いてきました。 LINEのフロントエンド組織UITでは、このような技術的なキャッチアップを日々行っています。 UIT INSIDE以外にも、毎週の社内勉強会で、フロントエンドの情報交換を行っています。今後も、UIT INSIDEを通じて、
@g4rds
このような情報を外部に発信していけたらと思います。最後に、現在、LINE株式会社では、新卒、中途採用ともに大募集しています。 このポッドキャストを聞いて、LINEに興味を持たれましたら、ショーノート1番下にある求人ページにぜひアクセスしてみてください。それでは、
@g4rds
uhyoさん、Alanさん、今日はありがとうございました。ありがとうございました。
@uhyo_
ありがとうございました。
