Slide 1

Slide 1 text

Hydrationから知るAstro, Qwik

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.)****

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

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コンポーネントをサーバーとクライアントの両方で レンダリングできます。

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Reactも使える

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Qwik

Slide 20

Slide 20 text

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)

Slide 21

Slide 21 text

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(継続可能性)

Slide 22

Slide 22 text

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.****

Slide 23

Slide 23 text

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.)

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

dev serverでのテスト

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

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.

Slide 34

Slide 34 text

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.

Slide 35

Slide 35 text

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:

Slide 36

Slide 36 text

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.

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

相違点 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

Slide 40

Slide 40 text

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