00:06
6月13日、月曜日ですね。 地獄は朝9時まいりました。
今日は、いい感じの天気ですね、東京も。 ありがとうございます。
おはようございます。 ゆめみのキース、このくわはらです。
では、本日も朝活を始めていきたいと思います。
はい、今日はですね、タイトル読むとおりですけど、
昨日まで、ソリッドJSの公式ドキュメントを 誰だろうと言ってたんですけど、
今日ですね、前日に言ったとおり、
SvelteとソリッドJSの比較記事があるので、 それをちょっと読んでいこうかなと思います。
タイトル的には、JavaScript UI Compilers コロンの
Comparing Svelte and Solidっていう感じですね。
っていう記事を読んでいこうかなと思ってます。
はい。あ、Kさんですね。 おはようございます。
ご参加いただきありがとうございます。
タイトルとおり、SvelteとソリッドJSの比較記事を 今からちょっと読んでいこうかなと思っています。
というわけで、早速入っていきましょう。 タイトルはさっきとおりですね。
はい、じゃあ入ってきます。
先月リリースされたSvelte3ですね。
先月ってことは、この記事は、 この記事でもちょっと古いですね。
2019年の5月14日なのでちょっと古いですね。
はい、Svelte3っていうのは、2019年のこれまでの フロントエンドUIライブラリの開発の中で
最も興味深いものになりました。
さらに言えば、付随する記事とビデオによる 立地破立の記事ですね。
Thinking Reactivityっていうのの記事があって、
これというものはしばしば 見過ごされがちなポイントを
しっかりと教えてくれるってことでした。
私にとってはこのビデオの23から25分あたりの内容が 特に注目のポイントだよって言ってますね。
コードを高速化するにはどうすればいいのか っていうところですね。
っていうのを注目、要は彼が取り除くことだ っていうふうにおっしゃってるそうですね。
はい。
あ、プテラノドさんですね。 ご参加いただきありがとうございます。
タイトルのとおりSvelteと SolidJSの比較記事を読んでます。
ちょっと古い記事なんであれですけど、
参考になるかもしれないというので読んでます。
続いていきますね。
Google IOの2019のウェブコンテンツの ほとんどを見たときに、
このメッセージは誰もが見ているものではない っていうことは明らかでしたと。
この数年、Googleっていうのはウェブコンポーネンツと ポリマーに動きを置きながら、
よりシンプルな新しいウェブの標準化を 描いてきたらしいですね。
今年はですね、今年っていうのは2019年は、
リアクトとビュートアンギュラーばっかりで、
バンドルサイズを意識しているときには、
Pリアクトというものか分からないですけど、
も少しあるよってことを言ってましたけど、
あとウェブアセンブリとかネイティブモバイルに 関する多くの講演と対になっていましたよってことですね。
サーバーサイズレンダリングのストリーミングや、
部分的なハイドレーティングっていうのを 延期した話を通して、
私はそのリッチのそれをすなさいっていう声を ずっと聞き続けましたよって言ってました。
確かに文脈っていうのはその代わり違いますよと。
文脈違うんですけど、
間違いなくその主張をより深く掘り下げることには つながったよと言ってましたね。
03:00
スベルトのJSフレームワークベンチマーク実装っていうのを 最新バージョンに更新をしてみましたよと。
実装コードは確かにスリムになりました。
パフォーマンスの向上はごくわずかでした。
あーなるほど。
コード量短くなったけどパフォーマンスは実は そんな変わってなかったよと。
スベルト3ですねこれ。
そんなことらしいです。
しかし実装をもう1KB減らしましたので、 その主張には一応沿うことができましたよと。
スベルト3っていうのは構文が大きく変わりましたが、 最終的にはこれまで通りの優れたパフォーマンスと
非常に小さなバンドルサイズを実現しています。
もともとパフォーマンスが悪くなかったってことですね。
つまり、実際にはピリアクトやあなたのお気に入りの たった2KBのライブラリよりも小さなバンドルを生成することが多く、
おそらくそれを上回るパフォーマンスを発揮するでしょう。
2KBって何を意味してるのかちょっとよくわかんないですけども。
しかし、それはまだ今日の話、私が本当に知りたいのは このアプローチに足があるかということです。
SolidJSっていうのはこのコンパイルアプローチを使用する例のアプリ、 別のアプリ、ライブラリですけども、方法論学となりますと、
リッチの主張をそれぞれ見て、誇張から事実を切り離すことを期待して、
それぞれのライブラリのアプローチを対比してみたいかなと思っています。
はい、その観点で引き続き読んでいこうかなと思います。
最初にパフォーマンス観点から入るそうですね。
パフォーマンスの図がちょっと出てくるんですけど、
図に関しては見せられないので、ちょっと口頭で頑張りますが。
はい、じゃあちょっと読んでいきます。
両ライブラリ、今回の比較記事がSolidとSolidですね、この比較になりますが、
両ライブラリはReactiveによる決め細やかな変更の伝播に基づいています。
全てがスプレッドシートの考え方。
スプレッドシートの考え方、どういうことや。
本文を読んでいくと、書いてないな。
書いてないけどなぜか翻訳ではスプレッドシートが出てくるな。
ちょっとこの翻訳はよくわからないですね。
このアプローチにはピンポイントの更新を行うための
オーバーヘッドをほとんど必要としないという利点があります。
多分仮想ドームを使わない話だと思いますね。
あれがオーバーヘッドだからそれを使わないという選択肢を
この両ライブラリアスしていたと記憶しています。
従来この種のライブラリのコストは
最初のレンダリングでリアクティブグラフをセットアップすることでした。
プリコンパイルというのはそのオーバーヘッドを大幅に削減して
この手法との相性を抜群に良くします。
そしてこの点は本当に最初に認識しておくべきことです。
まずスプレッドですね。
スプレッドは他のライブラリと同様に
JavaScriptのコードにバンドロされるライブラリです。
スプレッドが面白いのは
コンパイラーがあなたが使っている機能を認識し
スポット分の生成を巧みに自動化して
あなたが使う部分だけを
ESModules Tree Shakingに含めることができる点です。
06:02
ランタイムは小さいですけど
それなりのものにはなりますよって言ってますね。
なるほどですね。
僕らのソースコードから
使うものだけを検知して自動化するんですね。
なるほどでした。
それは確かにそこで
ESModules Tree Shaking含めることができるので
それは小さくはなりますよね。
性能のベンチマークには
Jace Frameworks Benchmarkというものを
使いました。
よくあるベンチマークの
サイトのアプリケーションを
使って検知したらしいですね。
残念ながら
リッチが公園で使っているベンチマークは
かなり使い物になりません。
厳しいですね。
しかも理由はそれだけではないと言ってますね。
理由はそれだけではなくて
なんだ?
ダン・アラモフさんという人が
別のことを言っているらしいですけど
この方がビデオの中で
言っている理由だけではないですよ
と言ってますね。
どんな理由か僕はビデオを見ていないので
わからないですけど。
このベンチマークはここで指摘され
ベンチマークの作者によって同意されたように
実際には全く役に立たないものを
テストしているんですと。
さらにこのスレッドでは
利益の実装が貧弱であることが
明らかに出ています。
一方、Jace Frameworks Benchmark
というのは
起動から更新まで、バンドルサイズ、メモリプロファイリングまで
含む全て
全方面のテストを提供しています。
なるほどですね。
リッチの用意したベンチマークは
結局は使い物にならないというところですね。
特にリアクトの実装は
しかも貧弱であったからあまり参考にならない
なのでよく使われているJace Frameworks Benchmark
というのを使って
一応ベンチマークを取ってみましたよということですね。
はい。
図がバーッと出てくるんですけど
その図はちょっと見れないので
記事のリンクは後ほどツイートしますので
その辺から見ていただければなと思います。
はい。
ご覧のように
特に近いものでありません。
Svelteは他の一般的なライブラリと
比較すると良いパフォーマンスを
持っていることは確かなんですけども
決してクラスをリードしている
わけではないと。
クラスというのはこのJaceライブラリの世界をということですね。
なぜSolidの方が
高性能なのでしょうかというところですけど
どちらのライブラリにも似たようなことをしますが
Solidの方が特に優れたパフォーマンスを
発揮する点が5つもあります。
それを今からちょっと説明していきますよ
ということですね。
一応そのSvelteと
Solid Jaceの比較を見ているんですけど
総合的に
一番早いのは結局
Vanilla Jaceで、その次がSolid Jace
次がInfernoですね。
第4位にRit HTMLが来て
第5位にやっとSvelteが来るわけですね。
そこから
オプリアクトとVueとリアクトと
Angularという感じで続くような
感じですね。
今回のこの人が比較で
抽出したライブラリはそんな感じです。
というわけで
SolidとSvelteだと
結構空いちゃってるんですね。
09:01
なるほどです。
総合的な面でということですね。
一個一個注目するといい勝負したり
どっちかというとSvelteの方が早かったりするみたいなのがありますけど
はい。
では一個一個読んでいきますね。
5つの優れた点ですけども
えーっと
ちょっと翻訳するので少々お待ちください。
一つ目ですね。
最適化された
DOMのリストコンシリエーションというところですね。
Svelteにも
キー付きのリストリーコンシリエーションが
ありますけども、より原始的な実装が
一応使用されていますと。
Svelteのリコンサイルっていうのは
非常に小さいんですけども、Solidのリコンサイルは
より洗練されていますと。
Svelteのアプローチっていうのは
Svelteのライブラリほど単純ではなく
全ての行を移動することなく
行の入れ替えを適切に処理していますけども
単一アイテムの変更操作については
ほとんど最適化されていませんと。
これがリストを扱う際の性能差の
大部分を示しています。
ざっくり言うとSvelteは
リストつまり配列の操作のところが
最適化されていないから
ちょっと遅いんじゃないのって話をしてますね。
これ結構
無視できない話な気がしますけどね。
2つ目は
テンプレートのクローンですね。
Solidでは
ノードを作成する際に
ドキュメント.クリエントエレメントの代わりに
ノード.クローンノードっていうのを使っています。
あーそうなんですね。
知らんかったわ。
ノードの方を使っているんですね。
これによって一時的なメモリの
使用量が削減されますと。
ちょっとお知らせですけども
ノードをプレスホルダーとして使用する必要がありますけど
少なくとも3つのノードが含まれる
繰り返しリスト
とかですね。
アイテム全体に影響がある場合は
ちょっと顕著になってきますよってことでした。
なるほどですね。
結構面白いですね。
ノードを作成する際に
ドキュメント.クリエントエレメントを使っていないと
ノード.クローンノードを使うんですね。
っていうのがSolidでした。
すべるとはじゃあ
ドキュメント.クリエントノードを使っているってことかなと思いますね。
続いて
3点目ですけど
Solidのデリゲーションですね。
Solidっていうのは
キャメルケースのイベントハンドラーに対して
暗黙のイベントデリゲーションを行っています。
これは
業ごとに2つの
ハンドラーを追加する処理をさせるよりも
パフォーマンスが高くなります。
明示的なイベント委任も
デリゲーションも可能ではあるんですけど
イベントタイプと業のデータ
失礼。
業のデータを結びつけるために
明示的なルックアップツリーっていうのを
トラバースを行うために
より多くのコードが必要になります。
で
以前のバージョンのスベルト実装では
これを行わなかったので
追加しませんでした。
現在スベルトコミュニティやリッチ自身が
パフォーマンスとより少ないコードを書くことの
相対的な重要性について意見を述べるのを
ちょっと待っているところです。
なるほどですね。
12:00
イベントとデータっていうのを結びつける
ルックアップだったり
ツリーのトラバースを行うために
より多くのコードが必要になってしまっている
っていうところが
スベルトの大きなデメリットっぽいですね。
なるほどです。
ソリッドはその辺を暗黙的に
行うように行ってますと言うけど
その処理、ソースコードが
長くならなかった理由が書かれてなかったので
それは何なのかちょっと気になりましたね。
はい。
この辺は僕の知識が弱いので
ふーんっていう話ですね。
続いていきます。第4点目ですね。
4点目は
同期更新のバッチ処理って言ってますね。
タイトル的には
シンクロナンスアップデートバッチングって書いてますけど
はい。
DOMを常に更新している場合
アニメーションフレームやプロミスなどで
更新を遅延させることっていうのは
パフォーマンスのためにはもちろん必要ではあります。
しかし単一の変更しか行えない場合は
更新のタイミングを遅らせることは
実はコストがかかります。
ライブラリーは一般に全ての更新を
一つずつ同期的に実行するか
遅延マイクロタスクでバッチ処理をします。
リアクトの
セットステイトを呼び出した後に
ステイト全体が更新されないのは
ご存知の通りです。
ソリッドっていうのは
アクションをバッチ処理するための
明示的な項目を提供して
そのセットステイトヘルパーは全ての変更を
同時に適用するリストを受け取ることができます。
ということですね。
はいはいはい。
なるほどです。
これがじゃあなぜ
早いのかっていうのは謎ではあるんですけど
遅延をさせることがなく
常に同期的にやっているから
早いってことかな。
ラスト5点目ですね。
明示的な反応と計算
Explicit reactivity
and computation
ですね。
なるほど。
ラスト5点目は
Svelteのコンパイラーっていうのは
ある値への接続を自動的に識別して
その値の変更を処理するために
必要な全てを自動的にセットアップしてくれます。
はい。
しかしその値を変更する意図があるかどうかを
判断することは困難です。
確かになるほどですね。
さらに
ReactiveやAtomなどですね
がそれが保持する値を
扱う意図を知るっていうのは
プレーンなJavaScriptの公文でも困難ですと
それもおっしゃる通りですね。
そのためコンポーネントのような境界で
追加の同期が必要になることが
あります。
Svelteのストア機構っていうのは
その辺が重いし
自動的なことがいいのかどうかっていうのを
改めて検討する余地があるんじゃないの
っていうのがこの筆者の主張っぽいですね。
なるほど。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
15:01
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
なるほど。
はい。
最後にボトムラインっていうのが
書いてあるんでボトムラインも読んでいきましょうか。
はい。結論ですね。
はフォトムラインって結論?
えー、知らなかった。
ソリッドのパフォーマンスは手作業で
最適化された場合にはuralascript 構造に
非常に近いためこのアプローチ
では生のパフォーマンスがボトルネックになる
ことはないと言えるでしょう。
はあ、なるほど。
実際パフォーマンスはプリコンパイルの最大の
強みの一つかもしれません。
今後のバージョンアップでスベルトのパフォーマンスは 向上する可能性も全然あり得ますよってことでした
この記事が2019年の記事なんで 改めてJS Frameworksベンチマークのサイトをアクセスして
見直してみたいなと思いました
同じライブラリーを抽出して 画面キャプチャーを撮ってみたいと思います
それも後ほど撮ったらTwitterに流しますね
続いてウライトレスコードで コードの記述量が短いことについて言及が入っているので
その辺も読んでいきたいと思います
ちょっと翻訳するんで少々お待ちください
じゃあ続いてウライトレスコードですね より少ないコードを書くということですけれども
より少ないコードでより少ないバグを書く
少ないバグを書くって翻訳面白いな
バグの量が少なくなりますって話だと思うんですけど
コードを少なく書くこととバグを少なく書くことは
明らかに何らかの相関があることは 誰しもが知っていることだと思いますし
知っていることをわざわざコーテーション付けているから ここは結構強調してますね
典型的な例というのは従業程度のコード LOCについて一つのバグというものです
そんな基準があるんですね
これが単なる偶然なのかそれとも認知的なオーバーヘッドの問題なのかは
人々が何でもかけて掘り下げてきたことです
私は正解が何であるかを知っているふりをするつもりはありません
直感的にはLOCや公文の冗長性よりも
式の数が関係しているような気がしています
そうですね 式っていうのがいわゆるロジカルのところを担当するので
その数に関係しているのはそうだと思います
変数宣言を複数行に渡って行うかどうかよりも
意思表示の数が関係しているというふうに思っています
というふうにSplittle3のリリースに向けて
リッチハリッドのWriteless Codeという記事を発表していますけど
これもざっと目を通す価値もやっぱりありますよと言ってますね
なるほどですね
意思表示の数が関係している 要は式の数がってことですよね
それは関係してそうですね
コードをより表現豊かにして書かれたコードが
18:02
暗黙のうちにあなたのために多くのことを行うようにするというのは
プリコンパイルが可能にする非常に説得力のある利点ではあります
プレーンなJavaScriptの代入というのは
意図が明確でノイズが少ないということに反論するのは難しいです
Splittleの$ラベルによる計算の指示というのは
UseEffectなどのReactよりもはるかに上調ではありません
Splittleというのは$をつけた変数をつけると
自動的に値を検知して変更してくれますよというのを
Reactiveを宣言するときに$をつけるんですけど
そういうものの指示というのは
UseEffectよりもまあまあ上調ではないよねって言ってます
だからSplittleのアプローチというのは
明らかにこの目標にアプローチするのに
最適なものに違いはないと言ってますね
おそらくですけどJavaScriptには信じられないほどの
表現力の高いものがすでに組み込まれていますと
それはいわゆる関数ですよと言ってますね
極端な話RxJSで書かれたコードと
命令型であるLinuxのコードを比べてみると
実装コードの量は全然違いますと
まあそうですねLinuxの一行のコードを見たことがあるでしょうかと
例えば
アクションドットスキャンの括弧でReducerをとりあえず置いといて
ではドットサブスクライブでRendererという感じですね
例えばのソースコードですけど
まあこういう書き方はLinuxは一応できますよと言ってますと
はいはい
確かにだいぶ短いですねLinuxであれば
Rxと書いたことある方はわかると思いますけど
確かにLinuxと比較するとコード量がだいぶ長くなるのは
確かに仕方ないなと思いますねこれは
そもそもアプローチと考え方とコンセプトが全然違うもんですから
とはいえ僕Rxは嫌いじゃないですけど
使うかっていうとうーんって感じはしますね
はい私はこれがバグ起こしやすいとか起こしにくいとかを
言ってるわけではもちろんなくて
ただコードを少なくしたいのであれば
コードの単純なオブジェクトアクセスや単純なHTMLテンプレートに
縮小するっていうのが実は解決策にならないかもしれない
っていうふうに言ってますと
JSXで関数からテンプレートを構成するっていうことは
コンポーネント化のオーバーヘッドを望まない
繰り返しの部分のコードを少なくすることに
つながることもまあまあありますよと
そうねで私の知る限り
Svelteではテンプレートパーシャルは機能としてはありませんと
あーそうなんやパーシャル機能は
この2019年バージョン3の時にはないと言ってますね
はいで実際に使ってみると
Solidの実装の方がコード量が少ない場合が多いことが分かりますと
でまあ一応この比較としてJS Frameworksベンチマークの実装で
リンクを置いてますよと言ってますね
で一応数字だけ見ていくと
Svelteの方は
例えばですけどねそのJS Frameworksベンチマークっていうもので
書いたアプリケーションのコード量でいくと
Svelteは97行ですね
21:00
Lines of Codeなので97行書きましたよと
でキャラクターでIncluding Spacesなので
これ単純に文字数ですね
文字数は3705文字
でWithout Spacesで文字数見ると
2829文字だそうですね
はいでそれと比較すると
Solidの方はLines of Codeが66行なので
実に31行短いですね
はぁ
でキャラクターです
Including Spacesなので
スペース含んだ文字数で3176文字なので
Svelteと比較すると何文字だ
529文字ですね529文字短いと少ないとですね
でさらにWhite Spacesを抜いた場合ですね
Without Spacesっていうのをやると2536文字
でこちらもSvelteと比較して
200何文字だ290違う280違う293文字ですね
293文字はい短いという感じであります
結構だからSvelteとSolidと比較してみても
意外とSolidの方が行数とか文字数短く
なるんじゃないのっていう話もしてますね
はいはいはいこれはちょっと意外でした
でボトムライン結論ですね
はい結論より少ないコードを書くためには
コンパイラーを使う最適な方法は何か
っていうのはまだ結論は出てないかもしれないですけども
プレーンなJavaScriptオブジェクトとか
名詞的なAPIのSurfaceっていうのを指さないほど
単純ではないですよと言ってますね
で表現力豊かなコンストラクトっていうのは
より名詞的でありながらプレーンな言語よりも
表現力豊かであることがよくあります
はいそうね
でシンプルであることと
簡単であることっていうのは全く異なることなんですと
あーこれいい話ですねはい
でえっととはいえこの2つの実装は
実装コードのサイズとしては
まあやっぱり最終の部類に入るので
あくまで1つの参考値程度に見てくださいって感じですね
はい本当にちゃんとよりでかいアプリケーションとか
それに特化した時にどうなるかっていうのは
ちょっとわかんないですけど
あくまで参考としてこのサイズだと
まあスベルトの方が
じゃあストリッドの方が短くかつ小さい
コード量になってよってことですね
ただまあ簡単であることとシンプルであることは
あくまでやっぱり異なるので
まあここは注目した方がいいかもしれないですね
はい続いてですけど
これ教授に読み切らない気がちょっとしてきましたね
続いてはスモールバンドルズですね
はいバンドルのサイズの話かなと思います
はい読んでいきましょう
スモールバンドルズです
このセクションは短いものになる予定ではありますと
スベルトはバンドルサイズに関しては
あなたが投げかけようとしている
ほとんど全てのものに対して圧勝しています
はい例外は全てのインポートが暗黙的であって
機能が非常にシンプルで
小さなDSL駆動のライブラリーかもしれませんと
というところだけ例外ですね
はいまあ
アップドームとかまあハイパーアップみたいな
ようなライブラリー懐かしい名前だな
ハイパーアップとかありましたね
のようなライブラリーっていうのは
ハイパースクリプトのような構文を使用して
24:00
使用する関数だけを簡単にかつ
明示的にインポートすることができますと
スベルトは確かに結構暗黙的ですよね
インポートらへん
でソリッドが使用されるものだけを含めるという
同じプリコンパイル手法を使用する場合でも
ソリッドのリストリックコンシージャーっていうのは
最小化バンドルにプラス3キロバイトを追加しますと
また表現力豊かなセットステートメソッドっていうのが
プラス1キロバイトですと
でより洗練された変更管理のコアっていうのは
プラス1.5キロバイトほどなので
イベントデリゲーションはさらに
プラス1キロバイト追加されます
はいはいはい
ちょいちょい追加されてますね
でスベルトのランタイム全体っていうのは
おそらくこれらのパーツを合体しても
実は足りないでしょうと
はーそうなんですね
でこれらはたとえオプトインであっても
一般的にはほとんどのコンポーネントに取り込まれるものですと
でスベルトと同じアプローチを使用する場合でも
ソリッドのパフォーマンスと少ないコード記述の
トレードオフにはバンドルサイズという代償が伴います
うんうんうんうん
しかしソリッドはランタイムコードを
ほとんど含まないように
縮小することができるという事実は
実際にはそれほど適用できませんと言ってますね
はーなるほど
でエディットなんですかね
エディットって読むのか
EDITっていう全部大文字なんですけど
はいでこちらはちょっと読んでいきますけど
ソリッド0.17.0ではサイズが劇的に超小さくなりましたと
はい
リストリミネーションコード
リストリミネーションコードってなんだ
初めて聞いた英単語でちょっと僕わかんないですけど
これリストリミネーションコードっていうのは約1kBに縮小されて
リアクティブコアっていうのは700Bに縮小されました
かなり小さいですね
リアクティブのコアなところ700Bなんですね
一般的なバンドルでは
ソリッドっていうのはプリアクトよりも小さく
このベンチマークでは
スベルトと数kBの差になりましたと
ソリッドは現在リアルワールドデモっていうのがあるらしいですね
そういうデモサイトがあるらしいですけど
で最も小さい実装の一つで
スベルトより25%も小さくなっていますと言ってました
はい
ちょっとこのリンクはあれなので
後ほどこれもツイッターに流しますね
ツイッターに流すのもちょっと増えますけど
はい
で最後結論
ボトムラインですね
はい
ちょっと言いますけど
使用されるものだけを含めるというこのアプローチにより
スベルトやソリッドのようなライブラリっていうのは
トランジッションや暗黙のイベント
デリゲーションなどの機能を
プロジェクトの常に重さをもたらす心配がなくなって
出荷することができますけども
それらの機能の実装が小さい場合にのみ
小さなバンドルを実装することができますと
はい
結局じゃあアプリケーション次第っていう風に言ってる気がしますね
うん
なるほどです
ただまあ
スベルトのその暗黙的なリアクティブとか処理に関しては
27:00
やっぱりあのソリッドJSが持っている
いろんなものを機能足し合わせて
全部ガチャンとやったものよりは大きくなるんじゃないのっていう
言及はしてましたね
はいそもそもこうなところで
あのソリッドの方が
スベルトよりも軽くなるんじゃないのって話ですね
はい
じゃあラストですね
ムービングフォワードです
はいラストここですけど
時間がちょっと多分ちょっとオーバーしてしまいますごめんなさい
あのお付き合いしたい時だけ
できる方だけ残っていただければと思います
最後
はいムービングフォワードですね
より今後の話です
けども
スベルトとソリッドっていうのは
どちらも現代のJavaScript UI開発の見方における
興味深い根本的な変化を表しているとは思っていますと
はいバーチャルドームっていうのはやはり
純粋なオーバーヘッドであるという考え方は賛成ですけども
全体的なメッセージはまとえていても
レドリックが単純すぎることが逆に懸念されますと
はい
各論に対する拍をつけるものが
あまりにも簡単すぎるんですよと
実際私は公平な見方をしたい人っていうのは
次の本を読むことをお勧めしますと
でその本っていうのは
ボリスコールっていう方の
ライブラリーの
なんだ
ボリスコールのライブラリー
イビっていうのがあって
それのリードミーですね
本っていうかそれを読んだ方がいいよって言ってますね
なるほどです
これちょっと軽く読んでみて
もし面白そうだったら明日読んでみようかと思いますね
はい
で彼は最もパフォーマンスの高いバーチャルドームライブラリーを書いて
そのトレードフについてすごい詳しく述べていますと言ってます
なるほど
でアプリが成長するにつれて
ある時点でサイズにおけるすべての利点のために
あなたはおそらくバンドルのほとんどを含むことになるでしょうということです
でツリーシェイキングっていうのは
スケールするのでしょうかっていう質問もありますけど
おそらくそれだけじゃないよと言ってます
興味深いのはこのコードスプリッティングと組み合わせた時に
どのようなことが可能になるかっていうことですと
で私はWebpackについてしか話せませんが
あそうなの
これはロールアップではすでに可能かもしれませんと
同じ静的解析を使って必要に応じて
複数のファイルにランタイムを分割できるのでしたらどうでしょうかというところですね
はい
でより大きなランタイムが最終的に避けられないのであれば
まあ少なくとも最初からすべてが必要ではないっていう合理的な可能性があります
もしこれがうまくいった場合
何が素晴らしいかというと
まあ派手な技術的メカニズムがないよって言ってますね
ライブラリーがサポートしている限り
これまでと同じようにダイナミックにスクリプトを読み込むだけでいいと
まあしかしここには何かがありますと
現在スベルトとソリッドの両方には欠点がありますが
このプリコンパイルアプローチが到達できる場所の可能性っていうのは
両方とも見ることができるよと
でソリッドはこのアプローチでパフォーマンスの最高峰が可能であることを示し
スベルトっていうのはそれが最小のバンドルサイズにつながることを示しましたと
ああ
なるほどですね
プリコンパイルのアプローチでは
ソリッドはあくまでパフォーマンスに注目をしていて
ソリッドっていうのはとにかくバンドルサイズを縮小するってところに注目をしているわけですね
30:00
どちらも最も合理的な構文を持ってより少ないコードで解析できるようになりますと
少ないコードで目指すところの方向が違うよということですね
ここは結構面白いですね
パフォーマンスを取るかバンドルサイズを取るか
ユーザーのギガを減らすように取るかっていう観点な気がしますけどね
さて取り除くっていうところですね結局は
いろんなものを取り除くっていうのはそれほど簡単ではないかもしれないですけど
しかし私たちがまだ表面を削ったに過ぎず
まだまだ探求する余地があるっていうのも十分感じているので
その辺が今後の我々の注目点だなっていうところで
お話を締めてましたね
はいっていう感じでした
比較調査されましたけども
大きくびっくりすることは特に僕の中であんまなかったかなって感じですね
あとこの記事自体はやっぱり2019年ちょっと古い記事ですので
どうなっていくのかっていうのはまだわかんないし
最新の記事を読んでみないとわかんないと思いますね
とりあえずいろいろ見ていって
最新のまずデータですね
JSベンチマークフレームワークベンチマークの2022年版が多分あると思うんで
そこを見ていってそのキャプチャーを見てリンクを送ったりとか
いろいろここを見た方がいいよっていうリンクがあったので
その記事も後ほどツイートしたいと思います
はいじゃあちょっと時間過ぎましたけど
今日の朝活はこちらで以上にしたいかなと思います
はい気づいたらめちゃめちゃ多くの方に参加していただいてちょっとびっくりしてますけど
はいご参加いただいた皆さんありがとうございました
はいじゃあ今日からまた月曜日ですね
一週間頑張っていきましょうお疲れ様です
