Overreactedに掲載された論考は、JSONが密閉された容器のように扱われすぎてきたと主張している。現在、ページがJSONに依存している場合、クライアントは通常、すべてのバイトが到着するのを待ってJSON.parseを呼び出し、その後になって初めて意味のある処理を始められる。筆者によれば、応答の一つの遅い部分が後続のすべてを滞らせるため、このモデルは現代のアプリには硬直的すぎる。筆者の見方では、ウェブにはそれより優れた選択肢がある。

この論考は、プログレッシブJPEGから発想の枠組みを借りている。プログレッシブ画像は、最初はぼやけており、時間とともに鮮明になるため、最終パスが届く前でも最初の表示が役に立つ。著者は、なぜJSONも同じように動作できないのかと問いかける。ストリーミング・パーサーは、ストリームが完了する前に未完成のオブジェクトツリーを公開できるべきだと、著者は提案する。そうすれば、一部のフィールドがまだ未解決でも、クライアントはより早く処理を開始できる。

問題は、未完成のデータが扱いにくいことだ。部分的に読み込まれたオブジェクトは、通常のコードから見ると不正な形式になり得る。形状がまだ安定しておらず、型チェッカーが欠けている要素の存在を前提にできないからだ。この論考によると、技術的には可能であるにもかかわらず、単純なストリーミングJSONが普及していない理由の一つはそこにある。未完成のオブジェクトしか返さないパーサーは、完全な結果を期待するアプリケーションロジックにとって、あまり使い勝手がよくない。

より興味深い提案は、データの送信方法を変えることだ。オブジェクトを深さ優先でストリーミングする代わりに、後から届く部分のプレースホルダーを設け、幅優先で送ることができる。こうしたプレースホルダーは、Promiseと考えることができる。クライアントは最初に最上位の外枠を受け取り、その後、空白を埋める追加の行を受信する。チャンクは厳密な順序で届く必要がないため、サーバーは、何をすぐ送信し、何を処理の遅い依存関係が解決するまで保留するかを決められる。

論考によると、これはReact Server Componentsの仕組みに近い。サーバーが行をストリーミングするにつれて、クライアントは段階的に読み込まれるツリーを再構築し、未解決の部分は関連するチャンクが届くまでPromiseのまま残る。この手法により、すべての依存関係の処理がすでに完了したかのように装うことなく、ページをより早く利用可能にできる。また、各部分をインライン化するか、別途アウトライン化するかについてサーバーの裁量が広がるため、重複を減らし、循環参照にさえ対応できる。

この主張が最終的に退けているのは、ストリーミングとは単にバイトを早く送り出すことにすぎないという考え方だ。真の目標は、早く届いたバイトを実際の処理に使えるようにすることだと、論考は述べている。クライアントが外枠を描画し、すでに取得したデータの処理を始め、Promiseが解決するにつれて残りを埋められるなら、転送モデルははるかに柔軟になる。その結果得られるのは、読み込みの高速化だけではなく、異なる形のアプリケーション・アーキテクチャである。

この論考のより根源的な主張は、早く届くバイトは、単に早いだけでなく実際の処理に使えるべきだということだ。クライアントが外枠を描画し、すでに取得した部分の処理を始め、残りをPromiseとして到着させられるなら、データが完全であるかのように装わなくても、アプリケーションは応答性が高いと感じられる。これはより要求の厳しいモデルだが、それだけ有用性も高い。