Think Qwik

Qwikは、高レベルでは他のWebフレームワークと非常によく似ています。Qwikは、インタラクティブなアプリケーションになるコンポーネントのツリーをレンダリングするフレームワークです。

Qwikのユニークな点は、何をするかではなく、どのように目標を達成するかです。Qwikの目標は、モバイルデバイスでも瞬時に起動するアプリケーションを実現することです。Qwikは、次の2つの主要な戦略を通じてこれを実現します。

1. 可能な限りJavaScriptの実行とダウンロードを遅延させます。
2. サーバー上のアプリケーションとフレームワークの実行状態をシリアライズし、クライアントで再開します。

Qwikの目標は、アプリケーションの最小限のコードのみをダウンロードして実行することです。

実行の遅延

可能な限りJavaScriptの実行を遅延させます。

Qwikアプリケーションの起動が速いのは、実行するJavaScriptコードの量が最小限であるためです。（最も単純な場合、Qwikアプリケーションがインタラクティブになるために必要なJavaScriptは約1KBのみです。）

アプリケーションのダウンロードと実行を積極的に遅延させることで、Qwikはほぼ瞬時の起動パフォーマンスを提供できます。現在の世代のWebフレームワークで、この実装に匹敵するものはありません。

Qwikが高速なのは、巧妙なアルゴリズムを使用しているからではなく、ほとんどのJavaScriptをダウンロードまたは実行する必要がないように設計されているからです。その速度は、他のフレームワークが行う必要があること（ハイドレーションなど）をしないことから生まれます。

再開可能性とシリアライゼーション

再開可能性については、こちらで詳しく説明しています。再開可能性により、Qwikアプリケーションはサーバーが中断した場所から実行を続行できます。すべてのフレームワークは、アプリケーションの状態に関する内部データ構造を追跡する必要があります。現在の世代のフレームワークは、サーバーからブラウザーに移行する際に、この情報を保持しません。その結果、フレームワークのデータ構造はブラウザーで再構築する必要があり、サーバーで行われた作業が重複します。データ構造の再構築とリスナーの添付は、ハイドレーションと呼ばれます。

Qwikは、サーバーとブラウザーのハンドオフ中に、リスナー、内部データ構造、およびアプリケーションの状態をHTMLにシリアライズします。すべての情報がHTMLにシリアライズされているため、クライアントはサーバーが中断した場所から実行を再開できます。

問題点とは？

現代のWebサイトがインタラクティブになるには、大量のJavaScriptが必要です。JavaScriptが多すぎると、次の2つの問題が発生します。

1. ネットワーク帯域幅：大量のコードがクライアントに送信され、低速なネットワークでは時間がかかる可能性があります。
2. 起動時間：クライアントに到着すると、サイトをインタラクティブにするために（ハイドレーションの一部として）コードを実行する必要があります。

Qwikアプリケーションがよりインタラクティブで複雑になるにつれて、コードの量は長年にわたって着実に増加しており、止まる兆候はありません。簡単に言えば、Qwikサイトはより複雑になっています。サイトの複雑さが増すと、今度はより多くのコードが必要になります。このすべてのコードは、サイトの起動パフォーマンスに悪影響を及ぼします。

さらに悪いことに、JavaScriptはシングルスレッドであるため、Qwikの複雑なサイトは最新のマルチコアCPUの利点を活かすことができません。

なぜこうなったのか？

上記の問題に対する解決策は、明白であると同時に困難でもあります。それは、JavaScriptの量を減らすことです。

明白な点は、JavaScriptが少ないサイトほどパフォーマンスが向上するということです。

難しい点は、私たちのツールがそれを実現するのを助けてくれないということです。Qwikのツールの大部分は、JavaScriptの量を減らすことを困難にする方法で問題を解決しています。これらのツールは、生成するJavaScriptの量を考慮せずに、特定の問題を解決するように設計されています。

レンダリング、スタイリング、アニメーション、A/Bテスト、分析などを解決する必要がありますか？それに対応するツールがあります。<script>タグをインポートまたは追加するだけで、これらのツールが問題を解決してくれます。しかし、その代償として、初期バンドルが大きくなります。

業界として、バンドルサイズの重要性は見過ごされがちでした。各ツールは特定の問題を個別に解決しますが、サイズは考慮されていません。すべてのツールが組み合わさるとサイズが問題になり、その時点で開発者ができることはほとんどありません。

解決策は？

Qwikは、サイズの問題に対処するためにゼロから設計されています。小さなバンドルサイズが最初の目標であり、他のすべての設計上の決定はその目標に従属します。

Qwikは、JavaScriptを減らすことを目的としていません。Qwikは、アプリケーションの起動時にすべてのJavaScriptをクライアントに一度に送信する必要がないようにすることを目的としています。Qwikは、「JavaScriptの遅延読み込み」という考えを極限まで突き詰めた結果として生まれるものです。

確かに、Qwikはアプリケーションの考え方と設計方法を変える必要がありますが、その結果、ユーザーインタラクションに基づいてJavaScriptを徐々にダウンロードすることにより、初期JavaScriptをほぼゼロにすることができます。

サイズは開発者の問題であってはならない

今日、サイズは開発者の問題です。各フレームワークやツールなどのベストプラクティスに従うと、バンドルサイズが大きくなってしまいます。その時になって初めて、開発者は何らかの遅延読み込みの境界などで問題の軽減を始めます。（しかし、これを行ったことがある人なら誰でもわかるように、選択肢は限られています。）

業界のベストプラクティスは大きなバンドルにつながり、ウェブには多くの例があります。

Qwikのモットーは、バンドルサイズは開発者が考えるべきものではないということです。フレームワークがどのように設計されているかの一部として自然に発生するはずです。

Qwikは、多くの遅延読み込み可能な境界を生成するようにゼロから設計されています。ツールはアプリケーションを多くの遅延読み込み可能なチャンクに分割でき、ランタイムは必要なときにのみそれらをダウンロードできます。

既存のフレームワーク/ツールを修正しないのはなぜですか？

簡単に言うと、遅延読み込みの哲学は低レベルで行う必要があり、既存のフレームワーク/ツールに根本的に変更を加えることなく遡及的に追加することはできません。このような根本的な変更は、フレームワーク/ツールおよびそれぞれのエコシステムと互換性がなくなり、それらを無効にしてしまいます。

フレームワークが、すべてのレンダリングが同期であるという特定の前提を立てている場合、非同期の遅延読み込みを追加することはほぼ不可能になります。また、フレームワークがテンプレートからリスナーの場所を回復する場合、サイトがインタラクティブになる前に、それらのテンプレートのダウンロードと実行が必須になります。これらは、より明白ないくつかの例にすぎませんが、実際には、現在のメンタルモデルが再開可能性の要件に適合しない理由は無限にあります。

上記は、既存のフレームワークが再開可能性を機能として追加することができないことも意味します。既存のフレームワークは、（後方互換性を損なうことなく）Qwikができることを決して行うことができません。

なぜQwikを構築しているのか？

なぜなら、サイトを構築するためのより良い方法があると信じているからです。サイトがインタラクティブになる前に、起動時に大量のJavaScriptを積極的にダウンロードする必要がない方法です。巨大なコードベースをより小さなチャンクに分割する方法ではなく、機能の追加について開発者が考えることを可能にする方法です。より良いユーザーエクスペリエンスのために、瞬時に起動するサイトを実現する方法です。そして、そのすべてを、アプリケーションのコードベースのサイズに依存しない方法で実現する方法です。

ページ速度は本当に重要ですか？

簡単に言えば、サイトが遅いと訪問者が遠ざかり、企業は何百万もの損失を被ります。サイトが速いほど、SEOが向上し、UXが向上し、より収益性が高くなります。

web.devからのいくつかの例