ローカルファースト HTMX pt1

概要

インターネット上では、事態は悪化しており、さらに悪化し続けているという意見がよく聞かれます。すべての Web サイトでひどい読み込み速度の速い広告が急増し、すべての検索エンジンが検索結果の前にくだらない AI 概要を表示し、すべてのサイト/Web アプリがどんどん遅くなっているように見えます。これらすべてに対する解決策を提供することはできませんが、Web サイトと Web アプリの設計のためのより良いパラダイムを示すことはできます。そのパラダイムはローカルファーストです。

ローカル ファーストは、UI とデータが同じ場所に配置され、データへの変更がリモート サーバーと同期される Web アプリの設計原則です。ローカルファーストアプリは、ユーザーのアクションとアクションの結果のレンダリングの間にネットワーク RTT を必要としないため、軽快でパフォーマンスが高いと感じられます。ファーストクラスのローカルファーストアプリがどのようなものかを体験するために、linear.app を試してみることをお勧めします。私は、悪い Web アプリについて説得するのに多くの時間を費やすつもりはありません。なぜなら、あなたが無知で幸せなら、私はその至福を台無しにしたくないからです。

Jira または Github の問題に精通している場合は、ローカルの最初のアプリがどれほど大きな違いがあるかをすぐに理解できるはずです。 Jira が遅いのは、私の知る限りでは単に 遅い であり、大量のデータのロードが遅く、クリックして離れて戻ると、そのすべてをリロードする必要があるためです。また同じデータ。 Github は SSR Web アプリであり、HTML がサーバー上で生成されて送信されることを意味します。これは、通常、対話にはブラウザとサーバーの間の完全な往復が必要であることを意味しますが、これは通常非常に顕著です。皮肉なことに、私の経験では、Github の遅い SSR は Jira よりもはるかに優れたパフォーマンスを発揮します。彼らは異なることを行いますが、私は Jira を使用するのが嫌いです。いつか Linear を仕事で使用できるようになり、現在と同じくらい高速になることを願うばかりです。

ここで一時停止し、実装が不十分な場合、ほとんどすべてのアプリ アーキテクチャが最終的にひどく遅くなる可能性があることを明確にします。私たちが毎日アクセスする Web サイトや Web アプリなどのほとんどは、適切に実装されていないと強く主張します。これらすべての異なるアーキテクチャ (従来の SPA、SSR など) で採用できるさまざまな技術がありますが、パフォーマンスに関連する場合、ローカル ファーストがアーキテクチャとして最も利点をもたらします。

ミーム主導の開発

それは私が意図していたよりも深刻だったので、ミーム駆動開発 (MDD) について少し掘り下げてみましょう。この投稿の本題に入り、Local First HTMX について話しましょう。

HTMX は...まあ、ミームであり、おそらく深刻なものでもありますが、本当に知っている人がいるかどうかはわかりません。 HTMX は、アンチ JavaScript の JavaScript フロントエンド フレームワーク/ライブラリです (フロントエンドの人々はこれらの用語を非常に大雑把に使用しています)。さらに重要なのは、これが本当に良いミームであり、それがMDDの鍵であるということです。そこで、まず HTMX とローカルを組み合わせて、本当にひどいものだが美しいものを作成する必要があると考えました。必ずしもこのアプローチを推奨しているわけではありませんが、最初の Local First HTMX Todo アプリを作成するために行ったことを共有できることに興奮しています。

HTMX は適切なフレームワークではありませんが、おそらく適切なフレームワークです

HTMX の目標は、良好なレベルの対話性を維持しながらフロントエンド開発を簡素化することです。 HTMX の一般的な考え方は、HTML がバックエンドによってレンダリングされる、つまりサーバーサイド レンダリングであるということです。専門用語では、HATEOS の状態のエンジンとしてのハイパーメディアです。 SSR (インタラクションごとにサーバーへの RTT が必要) にはパフォーマンスの問題があり、Web サイトが遅く感じる原因になる可能性があることを思い出してください (光の速度に対抗するのは困難です)。インタラクティブ性を散りばめるだけであれば、うまくいく可能性があります。しかし、これが Local First HTMX の重要なアイデアです。バックエンドで HTML をレンダリングする必要はありません。 "server" を構築し、それを WASM にコンパイルしてブラウザーで実行できます。これにより、JS をまったく使用せずに、ファーストクラスの Javascript Local First SPA のすべての機敏性が得られます。JS はほとんど使用されません。目標は、JS を避けることではなく、よりシンプルなアプリを作成することです。

アーキテクチャの概要

要約すると、SSR コードを WASM にコンパイルし、それを Service Worker で実行することで、Local First HTMX アプリを構築しています。簡単に、そしておそらく間違っているかもしれませんが、ブラウザーについていくつか説明させてください。メインスレッドがあり、通常はここで JS と HTML の処理が行われます。メインスレッドは DOM にアクセスし、実際にコンテンツをレンダリングできるスレッドです。ブラウザには多くの機能が追加されていますが、ここでは 2 つの機能について触れたいと思います。 1 つ目は Web ワーカーで、権限が制限されている (DOM へのアクセス権がない) 別のスレッドでコードを実行できます。 2 つ目はサービス ワーカーです。これは Web ワーカーに似ていますが、重要な違いがあります。 Service Worker は、すべての fetch リクエストをインターセプトするように構成できます。

Service Worker は、プロキシを作成したり、キャッシュを確認したり、リクエスト自体を処理したりするなど、必要なことを行うことができます。これが私が利用したいことです - すべてのフェッチリクエストをプロキシし、オプションで HTML をレンダリングして送り返すことを選択します。

基本的な HTMX リクエストは次のようになります

<button hx-post="/clicked"
    hx-trigger="click"
    hx-target="#parent-div"
    hx-swap="outerHTML"
>
    Click Me!
</button>

通常、これは HTTP リクエストをサーバーに送信しますが、Service Worker でこのリクエストをインターセプトし、リクエストを処理して HTML を返したいと考えています。その後、Service Worker はローカル データ ストアを維持しながら、バックグラウンドでサーバーとデータを同期できます。フォローアップの投稿では、これを行った方法の実装の詳細と、遭遇したいくつかの問題について説明し、さらにいくつかのアイデアについて説明します。

ご期待ください。

以上がローカルファースト HTMX pt1の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。