Hydrationから知るAstro, Qwik

はじめに どちらもまだ若いFWです いずれかの使用を積極的に推奨する意図はありません どちらもデファクト・スタンダードたるNext.jsの対抗馬としてのPRの仕方が上手だなあ という印象を持っています 別の分野ですが、ビルドツールも新しいものが出るたびに自分達に有利な速度比較 表を出しがちなので、現実世界でどのくらいの差をもたらすかということや、エコ システムがどれくらい発達しているか等もきちんと考慮にいれて技術選定しましょ う

Hydration ? https://nextjs.org/docs/basic-features/pages#pre-rendering Each generated HTML is associated with minimal JavaScript code necessary for that page. When a page is loaded by the browser, its JavaScript code runs and makes the page fully interactive. (This process is called hydration.)****

SSR(or SSG)しない場合 空のHTML + JSを返却 JSを実行 仮想DOM組み立て 仮想DOMをもとにDOM生成＆イベントハンドラのアタッチ

SSR(or SSG)する場合 サーバーサイドで（または事前ビルド時に）JSを実行 仮想DOM組み立て 仮想DOMをもとにHTML文字列を生成 生成したHTML + JSを返却 仮想DOM組み立て — ここからhydration — 仮想DOMとHTMLの差分を検出 通常は差分なしのはずなのでなにもしない 差分がある場合はその部分のDOM生成をやりなおす イベントハンドラのアタッチ — ここまでhydration —

Astro https://docs.astro.build/ja/getting-started/ Astroは、コンテンツにフォーカスした高速なWebサイトを構築するためのオール インワンWebフレームワークです。

https://docs.astro.build/ja/getting-started/ 主な特長 コンポーネントアイランド： 高速なウェブサイトを構築するための新しいウ ェブアーキテクチャー。 サーバーファーストのAPI設計： ユーザーのデバイスから高コストのハイドレ ーションをなくします。 デフォルトでゼロJS： サイトを遅くするJavaScriptランタイムオーバーヘッ ドはありません。 エッジ対応： DenoやCloudflareのようなグローバルなエッジを含め、どこで もデプロイできます。 カスタマイズ可能： Tailwind、MDX、その他100以上のインテグレーションか ら選択可能です。 特定のUIに依存しない： React、Preact、Svelte、Vue、Solid、Litなどをサポ ートします。

https://docs.astro.build/en/concepts/islands/ Astroアイランド（別名：コンポーネントアイランド）は、Astroが開拓したWebア ーキテクチャーのパターンです。「アイランドアーキテクチャー」のアイデアは、 2019年にEtsyのフロントエンドアーキテクトであるKatie Sylor-Millerによっては じめて作られ、Preact作者のJason Millerによってこの投稿で広められました。

https://jasonformat.com/islands-architecture/ The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions. These placeholders/slots contain the server-rendered HTML output from their corresponding widget. They denote regions that can then be "hydrated" on the client into small self-contained widgets, reusing their server- rendered initial HTML.

No content

https://docs.astro.build/en/concepts/mpa-vs-spa/ Astroは、MPAフレームワークの1つです。しかし、Astroは他のMPAフレームワー クとは一線を画しています。その大きな違いは、サーバー言語とランタイムに JavaScriptを使用している点です。従来のMPAフレームワークでは、サーバーに別 の言語（RubyやPHPなど）を書き、ブラウザにはJavaScriptを書くことになりま す。Astroでは、常にJavaScriptとHTML、CSSを書くだけです。そうすれば、 （ReactやSvelteのような）UIコンポーネントをサーバーとクライアントの両方で レンダリングできます。

https://github.com/AsazuTaiga/astro-blog .astro コンポーネント

Reactも使える

mdxでブログもかける Reactコンポーネントは client: load しないとインタラクティブになるためのjs が読み込まれないのでちゃんと動かない ほかにも client: idle とか client: visible などと読み込みタイミング を制御できる https://docs.astro.build/ja/reference/directives-reference/#client-directives

No content

https://blog2.asazutaiga.dev/blog/test

https://docs.astro.build/ja/core-concepts/framework-components/#インタラクティブ なコンポーネント client:* というディレクティブの内の1つを使用してフレームワークのコンポー ネントをインタラクティブ（ハイドレーションした状態）にできます。これはコン ポーネントがどのようにレンダリングされ、ハイドレーションされるかを定義する ためのコンポーネントの属性です。 このclientディレクティブ (EN)はコンポーネントがビルド時にレンダリングされる かどうか、コンポーネントで使用されているJavaScriptがクライアントサイドでい つブラウザに読み込まれるかを表しています。 ほとんどのディレクティブでビルド時にサーバー内でコンポーネントをレンダリン グします。コンポーネント内のJavaScriptは特定のディレクティブに応じてクライ アントに送信されます。コンポーネントは自身に含まれるJavaScriptをインポート し終えた段階でハイドレーションします。

コンポーネントのフレームワーク（たとえばReact、Svelteなど）がレンダリングする のに必要なJavaScriptはページと一緒にダウンロードされます。 client:* というディ レクティブはいつコンポーネントで使用されるJavaScriptがインポートされるかと、い つコンポーネントがハイドレーションされるかを決定するだけです。 いろんなFWのコンポーネントを混ぜ書きできるともいえるが、それぞれのFWを動かす ためのランタイム(reactパッケージ本体等)はダウンロードせざるをえないので、あまり やりすぎるとよくなさそう

Qwik

https://qwik.builder.io/docs/overview/ Qwik is a new kind of web framework that can deliver instant loading web applications at any size or complexity. Your sites and apps can boot with about 1kb of JS (regardless of application complexity), and achieve consistent performance at scale. Astroとの姿勢の違いが出ていて面白いね（sites and apps）

Instant-on Unlike other frameworks, Qwik is resumable which means Qwik applications require 0 hydration. This allows Qwik apps to have instant-on interactivity, regardless of size or complexity キーワード: resumable（継続可能性）

Optimized for speed Qwik has unprecedented performance, offering sub-second full page loads even on mobile devices. Qwik achieves this by delivering pure HTML, and incrementally loading JS only as-needed.****

https://qwik.builder.io/docs/think-qwik/ Core principle Delay execution of JavaScript as much as possible. Qwik applications startup fast because there is a minimal amount of JavaScript code to execute. (At its simplest, a Qwik application only needs about 1KB of JavaScript to become interactive.)

https://qwik.builder.io/docs/concepts/resumable/ Hydration is expensive for two reasons: i. The frameworks have to download all of the component code associated with the current page. ii. The frameworks have to execute the templates associated with the components on the page to rebuild the listener location and the internal component tree. Qwik is different because it does not require hydration to resume an application on the client. Not requiring hydration is what makes the Qwik application startup instantaneous.

No content

dev serverでのテスト

No content

No content

No content

No content

No content

FAQs（抜粋） https://qwik.builder.io/docs/faq/ Does Qwik download JS when the user interacts? Nope, in production Qwik uses a lot of information generated during SSR to start prefetching only the bits of interactivity of the current page as soon as possible (ASAP), this way when the user clicks or interacts, the JS is already downloaded.

Does Qwik do partial hydration? No, Partial hydration (or island architecture) popularized by Astro is about preventing full-page hydration, where all existing components in the page need to be downloaded and executed, and instead breaking the app into islands of interactivity. Islands that developers need to manually define, and then manually describe in which situations they should be hydrated. Islands that can not communicate between each other. Instead, Qwik components does not hydrate at all. Qwik achieves this through a powerful serialization system, that serializes only the necesary state the reactivity graph, so app can resumes without eagarly running any JS. We think resumability scales without the negative trade-offs of partial hydration.

Resumablitiy ? https://qwik.builder.io/docs/concepts/resumable/#component-trees Introducing Resumability Resumability is about pausing execution in the server and resuming execution in the client without having to replay and download all of the application logic. A good mental model is that Qwik applications at any point in their lifecycle can be serialized and moved to a different VM instance (server to browser). There, the application simply resumes where the serialization stopped. No hydration is required. This is why we say that Qwik applications don't hydrate; they resume.

event listners click me component trees Qwik collects component boundary information as part of the SSR/SSG and then serializes that information into HTML. The result is that Qwik can:

application state Existing frameworks usually have a way of serializing the application state into HTML so that the state can be restored as part of hydration. In this way, they are very similar to Qwik. However, Qwik has state management more tightly integrated into the lifecycle of the components. In practice, this means that component can be delay- loaded independently from the state of the component. This is not easily achievable in existing frameworks because component props are usually created by the parent component. This creates a chain reaction. In order to restore component X, its parents need to be restored as well. Qwik allows any component to be resumed without the parent component code being present.

余談: Contextの型チェックが微妙 CTX を引数に渡してるんだからそこはいい感じにしてくれ などの細かい部分にまだproductionは厳しい感じが出ている まだ0.X系だしね "@builder.io/qwik": "0.12.0", "@builder.io/qwik-city": "0.0.118",

共通点/類似点 HTML First(NOT JS First) 可能な限りJSのロードを減らす（Astro, Qwik）or遅らせる（Qwik） 表示の速さ=表示に必要なファイルサイズの小ささ

相違点 MPA or SPA Astro: MPAを名乗っている Qwik: RouterとかもあるしどっちかというとSPAっぽい SPAがSSRし始めた段階であんまりSPA, MPAとか意味ないかもしれん Hydration Astro: Partial Hydration Qwik: No Hydration ( Resumable ) 利用シーン Astro: Website WebApplicationとして使えないこともないが Qwik: Website, WebApplication

おわりに どちらもまだ若いFWです いずれかの使用を積極的に推奨する意図はありません どちらもデファクト・スタンダードたるNext.jsの対抗馬としてのPRの仕方が上手だなあ という印象を持っています 別の分野ですが、ビルドツールも新しいものが出るたびに自分達に有利な速度比較 表を出しがちなので、現実世界でどのくらいの差をもたらすかということや、エコ システムがどれくらい発達しているか等もきちんと考慮にいれて技術選定しましょ う