Qwikというフレームワークについて

Qwikの特徴

• 遅いモバイル環境だとしても、TTIを爆速にすることを目的としたフレームワーク
  • TTI: Time To Interactive
  • ページが読み込まれて、UIが表示され、イベントハンドラがアタッチされ、操作可能になるまでの時間
• Resumableをテーマに作られている
  • 詳細は後述
  • 現状のフレームワークたちはどれもResumableではなく、強いて言うならReplayable
• JSではなく、HTML(DOM)を中心とした設計になってる
  • 内部状態の管理などに、JSのヒープではなくDOM属性の文字列を使う
  • JSが不要というわけではない

という具合で、これまでのものとは一線を画する感じ。

現状のフレームワークとTTIの問題

TTIまでに必要なステップは、ざっくり次のとおり。

• クライアントがページをリクエスト
• サーバーがそれを受けてSSR
  • CDNなどから返すでもいいけど、それだとCSRが必須になってしまう
  • 遅いモバイル環境でも最速を目指すなら、SSRしかない
• HTMLとJSのダウンロード
  • HTMLはたいていすぐ取得できるけど、問題はJS
• ダウンロードしたJSの実行
  • テンプレの構築やイベントハンドラのアタッチなど
  • いわゆるハイドレーション

Nextなど現状のフレームワークを使う場合、この後半のステップが重くなりがちで、どうしてもTTIが遅くなる傾向にある、と。

ほとんど静的なページだったとしても、デカいランタイムが必要（Svelteみたいにそこが小さいのもあるけど）になるし、イベントハンドラをアタッチするためにVDOMを全走査したりしないといけない。

そうやってJSをロードしてすべてのUIにハンドラをアタッチしても、ユーザーがそれらを必ず使う保証はないという別の問題もある。もしそれらが使われなかったら？その部分のイベントハンドラ（およびその裏側のクロージャに連なる多数の依存コード）や、テンプレですらも無駄になる。

ただこれはそういうデザインになってるからであって、それが必ずしも悪いというわけではない。そのおかげで以降のランタイムのパフォーマンスは良くなるので、何事もトレードオフ。

Qwikのデザイン

TTIを速くするには、そういう初期ロードでのJSのダウンロードや実行をやめる、もしくは遅延させる必要がある。

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

もちろん他のフレームワークでも、遅延ロードするように手書きすることはできる。けど、それは付け足しであって、コードは確実に煩雑になるはず。

Qwikの場合、遅延ロードするのがデフォルトなので、そのための特別なコードは必要ない。単にQwik-wayにコードを書けば、それだけで遅延ロードされる。そんなすべてを遅延ロードするデザインを可能にしてるのが、最初に言ってたResumableという概念。

<div
  on:q-mount="./q-fbbfca2f#Counter_onMount"
  on:q-render="./q-35fc9755#Counter_onRender"
  count-step="5"
  q:obj="#2 !:22l6t4ye9i5"
>
  <div>
    <button on:click="./q-3f6b5546#Counter_onRender_on_click">-5</button>
    1
    <button on:click="./q-4e593eee#Counter_onRender_on_click5">+5</button>
  </div>
</div>

コードを動かす、試す

実際に動いてるものを見るなら、

• Qwikの中の人たちであるBuilder.ioのサイト
  • https://www.builder.io/?render=qwik
  • パラメータに注目
• TODOのデモ
  • https://stackblitz.com/edit/qwik-todo-demo
  • ただしChrome系のブラウザでしか見れない
  • そしてQwikのバージョンが古いので、コードは参考にならなそう

確かに、初期ロードは軽いしめっちゃ速い気がする・・！

さっきの`Counter`コンポーネントはこんな感じで書いてた。

import { h } from "@builder.io/qwik";
import { qComponent, qHook } from "@builder.io/qwik";

export const Counter = qComponent<{ countStep: number }, { count: number }>({
  onMount: qHook(() => ({ count: 1 })),
  onRender: qHook((props, state) => (
    <div>
      <button
        on:click={qHook<typeof Counter>((props, state) => {
          state.count -= props.countStep;
        })}
      >
        -{props.countStep}
      </button>
      {state.count}
      <button
        on:click={qHook<typeof Counter>((props, state) => {
          state.count += props.countStep;
        })}
      >
        +{props.countStep}
      </button>
    </div>
  )),
});

という感じで、

• `class`ではなく、`qComponent()`にオブジェクトを渡してコンポーネントを作る
  • `onMount()`で、コンポーネントに閉じた状態を返す
  • `onRender()`で、おなじみのJSXを使ってテンプレを書く
• `qHook()`でラップすると、コンポーネントのPropsやStateにアクセスできる
• CSSはクラスを振って書くしかなさそう
  • ただしオブジェクトを渡せば`true`のときに付加するみたいな仕組みはある

これはできる限り現状のフレームワークっぽい書き方でComponentにすべてを詰め込んでるけど、Qwikの真髄的には、ViewとStateとHandlerはそれぞれバラして書くべきらしい。そのほうが、本当に必要なものだけを遅延ロードできるから。

Your bundler is doing it wrong - DEV Community

ただこのへんはコンパイラがいい感じにやってくれる？っぽい感もあって、まだよくわかってない。

Qwik compiler playground

Rollupのプラグインとして動いてるであろうOptimizerでもその具合を調整してる風だった。推論できないときのためのマーキングなんだろうか・・？

ローカルで試したい場合は、スターターのコマンドを使う。

npm init qwik

ってやると、いくつかテンプレを選ぶだけでコードを書き始められる。

現時点のデプロイ先の選択肢には、Node.js用の`express`のバージョンと、Cloudflare Workersへデプロイできるバージョンの2つがあった。たしかにコレはWorkerでやれると良さそうって思ってたんよね。

スターターを使って、

• もっともベーシックな`Starter`プロジェクトを
• Node.jsでデプロイする

とした場合に、生成されたコードはこのような感じ。

├── README.md
├── package.json
├── rollup.config.js
├── server
│   └── index.js
├── src
│   ├── index.server.tsx
│   └── my-app.tsx
└── tsconfig.json

`src`配下がアプリのコードで、この状態でビルドすると、こうなる。

├── README.md
├── package.json
├── public
│   └── build
│       ├── index.server.js
│       ├── my-app.js
│       ├── q-1612aa57.js
│       ├── q-5404689f.js
│       ├── q-6c8e2d16.js
│       └── q-8b22cd88.js
├── rollup.config.js
├── server
│   ├── build
│   │   ├── core-3865dc2e.js
│   │   ├── h_my-app_myapp_onmount-4f2b0222.js
│   │   ├── h_my-app_myapp_onrender-e999a192.js
│   │   ├── h_my-app_myapp_onrender_on_keyup-69b97bcc.js
│   │   ├── index.server.js
│   │   ├── my-app.js
│   │   └── q-symbols.json
│   └── index.js
├── src
│   ├── index.server.tsx
│   └── my-app.tsx
└── tsconfig.json

`server/build`配下にSSRのために必要なアプリのコードが出力されて、クライアントに返して使うための同様のものが、`public/build`配下にできるという感じ。とにかく細かいファイルが作られて、必要なときに必要なものだけが利用されるってのがよくわかるはず。

Cloudflare Workersにデプロイする方式を選んだ場合は、Workers Sitesを使ってホスティングするようになってた。

おわりに

というわけで、TTIが速いのは納得のデザインって感じでかなり好印象だった。TTIをKPIに据えてるなら、選択肢として考えられるようにしていきたい感じ。

ただ、UIイベントが発生してからハンドラのコードをリクエストするので、UIとしてのレスポンスにはいくらか制限があるんでは？とも思った。キャッシュしたりWorker使ったり、ある程度はカバーできると思うけど。

まだ生まれて間もないし（というかドキュメントすらないし）、実用段階ではないにしても、これからも要チェックでいきたいところ。

JSの用法と用量を最適化しようとする昨今のトレンドは割といいなと思っていて、そういう意味ではAstroとかと出発点は同じなのかもなーと。SSRのQwikと、SSGのAstroみたいな。

ちなみにQwikの中の人、あのAngularの中の人でもあるそうな。ここでまたその名を聞くとはな・・どうりでそれらしいコードやらコメントやらがあるわけやって感じ。

ほかにもBuilder.io社のOSSは興味深いのが多くて、`partytown`とか`mitosis`とか、一度は話題になってたことがあるはず。