Qwik
https://gyazo.com/a9301542dd1d377da2681691e6d02ca9
Resumable がポイント
SSRにある Hydration というのものをなくし、 Resumable でリアクティブを担保とのこと
https://gyazo.com/57053411fe35ef74e8df0e8bf8212ace
HTML ファースト
パフォーマンスの良さを売りにしている
アプリケーションの規模が大きくなっても JSのサイズが変わらないらしい
Why Qwik?
Core principle
Delay execution of JavaScript as much as possible.
Resumable -> Hydration の問題を改善したもの
p10
アプリケーションの規模によって初期ロードのJSサイズが変わらない初の O(1) フレームワーク
https://gyazo.com/52eaed1e38e58429d812e270988f98f7
そもそも Hydration とは？
SSR や SSG にてサーバーサイドでレンダリングされた HTML に対してイベントリスナを登録し、ページをリアクティブにするまでの一連の処理のこと
これの何が問題？
既に一度サーバーサイドでHTML化されているコンポーネントのJSを再度ダウンロードし、パース&実行する必要がある点がオーバーヘッド
いろいろな解決法
Hydration の実行を非同期化し遅延させる
React 18 の Slective Hydration Hydrarion を行う部分を限定して分離する
Hydration を行わずHTMLに状態をシリアライズする
これが Qwik のアプローチ
記事の中でNext.js と Qwik とで同じアプリ実装をして、ロードするJSのサイズ比較をしている
Qwik の方が初期ロードにおけるファイルサイズが小さかった
Qwik の特徴
遅いモバイル環境だとしても、TTIを爆速にすることを目的としたフレームワーク
TTI: Time To Interactive
ページが読み込まれて、UIが表示され、イベントハンドラがアタッチされ、操作可能になるまでの時間
Resumableをテーマに作られている
詳細は後述
現状のフレームワークたちはどれもResumableではなく、強いて言うならReplayable
JSではなく、HTML(DOM)を中心とした設計になってる
内部状態の管理などに、JSのヒープではなくDOM属性の文字列を使う
JSが不要というわけではない
TTI が遅くなるのは JSのダウンロードや JSの実行箇所（Hydration)
ユーザが使わないかもしれない箇所も初期化している
Qwikの場合、遅延ロードするのがデフォルト
ユーザが使う時に使う分だけロードする
@mizdra: qwik、「HTML 属性にイベントリスナーの定義場所を書いておき、ランタイムがそれを一括で管理することで hydration 不要でイベントリスナーの登録を実現する」「イベントリスナーが呼び出されたタイミングでテンプレートのコードを DL してくる」というアプローチの組み合わせが発明っぽい