Qwikというフレームワークについて - console.lealog();

Qwikというフレームワークについて - console.lealog();
Nextなど現状のフレームワークを使う場合、この後半のステップが重くなりがちで、どうしてもTTIが遅くなる傾向にある
わかる
ほとんど静的なページだったとしても、デカいランタイムが必要(Svelteみたいにそこが小さいのもあるけど)になる

Qwikでも初期ロードでJSを利用するけど、それは1KB足らずで実行も1ms以内に終わる。あとの全て(UIもイベントハンドラも何もかも)は、非同期で遅延ロードされる

現状のフレームワークたちはResumableではなく、Replayableと言ってたけどそれは、
フレームワークの内部状態が、JSのヒープで管理されてる
イベントハンドラがどこにアタッチされるか
コンポーネントの構造
状態のバインディング
その解釈や評価がロード時に行われる
そのために、大量のJSが必要になるわけではある
SSR時にやったはずのことを、"リプレイ"する必要がある
途中でやめることも、一部だけをハイドレーションすることもできない
いわゆるパーシャルハイドレーションができない
という特徴があるから。
このデザインだと、どうしてもTTIに不利であり、アプリのサイズが大きくなればなるほど、もっと不利になる。
それに対してQwikでは、
SSRでやったことを、クライアントで引き継げる
つまり"レジューム"できる
そのためには、引き継ぎ情報をサーバーからクライアントに渡す必要がある
それに使われるのが、DOMの属性(= Attributes)
ありとあらゆるものが、シリアライズされて属性値に書かれる
イベントハンドラやコンポーネントの状態、再描画が必要というマーキングなども
レジュームできるということは、途中でやめることも容易
スクロールしないと表示されないようなUIは、後回しにできる
いわゆるパーシャルハイドレーションができる
という風になってる。
islands architecture のアプローチとは違うパーシャルハイドレーションの実装て感じかなあ

イベントハンドラですら遅延ロードされる。実際にクリックされるまで、ハンドラで実行するコードをダウンロードすらしない!インクリメントのハンドラと、デクリメントのハンドラも別ファイルになる。クリックされたら、その当該のハンドラと、テンプレのためのコードがダウンロードされて実行される
限界チューニングて感じする

#20220908 #0908


関連ページとランダムに選ばれたページ

筆者について

jigsaw(ジグソウ、1991年6月12日-)は日本のプログラマ、会社代表。本名は小林貴也(こばやし たかや)。主にウェブ、フロントエンド領域で活動している。カミング・スーン合同会社の代表社員。
さらに詳しく

寄附について

面白かったらBTCETHでの寄附をお待ちしております。
寄附のきろく