Progressive JSONとは？ データストリームと段階表示で快適UIを実現する考え方
引用元：https://news.ycombinator.com/item?id=44147945
この記事を文字通り「Progressive JSON」っていうフォーマットを著者のDan Abramovさんが提案してるって受け取ってる人がいるみたいだけど、そうじゃないよ。
これはReact Server Components（RSC）のアイデアを説明する投稿に近いね。コンポーネントツリーをJavaScriptオブジェクトとして表現して、この記事に似たフォーマットで（機能も似てるけど、僕の知る限りbundlerとかframework固有かな）ワイヤーでストリームするんだ。
これでReactはツリーに（ローディング状態を表す）「穴」を持たせて、初回ロード時にフォールバック状態を表示できるし、サーバーが実際にデータを提供できるようになった後にだけ、ロードされたコンポーネントツリーを表示するんだ（つまり、フォールバックのスピナーやスケルトンをもっと速く、きめ細かく表示できるってこと）。
（細かく突っ込むと色々と間違ってるかもしれないけど、大筋は合ってると思うよ）
うん！まぁ、正直言って、書かれてるアイデアを元にみんなが何か別のことをしても全然構わないと思ってるよ。RSCのデータシリアライズについて、あまりReactに特化してるように見えない形で説明したかったんだ。アイデア自体は実はもっと一般的だからね。RSCで僕が見たアイデアが他の技術にもっと広まったら嬉しいな。
やあ、Danさん！すごく面白い投稿だね。
JSON-LDみたいに行ベースで、だからストリームできる、生成やパースがもっと簡単な新しいデータシリアライズフォーマットは、何か役に立つと思う？
どうかな！そういう問題に直面してるか、それを解決する手段があるかに依ると思うな。RSCはまさにそのために設計されたんだ。だから僕はその設計の選択肢を説明しようとしたんだよ。もしシリアライザを作ってるなら、そのフォーマットの特性について考える価値はあると思うよ。
素晴らしいね、ありがとう！問題には直面し続けてるけど、Danさんが言うように、レバー（手段）がないのが実装を難しくしてるんだ。
今のところ、LLMを呼び出すのに使ってるJSONツールをvLLMみたいに完全に制御できるものに置き換えるくらいしかできないかな。大手ラボはツール呼び出しごとに20-30％余計なトークンを課金して満足してるだろうから、JSONを置き換えることにはすぐには興味ないだろうね）。
それに、すでに標準になってる巨大なものと戦ってる感じもするし、引用符とか波括弧とかにトークンを無駄遣いしないことで20-30％余計なトークンウィンドウを稼げるような、本当に専門的なワークフローでなら居場所があるかもね（お金だけじゃなく）。
返信ありがとう！
以前Reactを使っていくつかアプリやコンポーネントを作ったことがあるけど、RSCには詳しくないんだ。
すぐに頭に浮かぶのは、代わりにユニフォームな再帰ツリーを使うことかな。各ノードが同じフィールドを持ってるんだ。ちょっと考えるとDOMに似てるかもね。各ノードがそのタイプ、ID、名前、値、親ID、順番とかをエンコードするんだ。手前のエンジンがこれで汎用的に適切な場所に配置できる。
ここでそれが可能かどうかは分からないけど、ただの思いつきだよ。データ駆動のReact（や他の）アプリで似た構造を使ったことがあるんだ。
メモリ上でも効率的にエンコードできるんだよね。フラットでコンパクトな配列に入れられるから。SQL DBにもうまく収まるよ。
GraphQLにも似たような概念があるよ。例えば@deferとか@streamとかね。
プログレッシブローディングが嫌いなのって僕だけ？特にコンテンツが飛び跳ねるやつ。
そして一番イライラするアンチパターンは、ローディング中に空の状態のUIを見せることなんだよね。
その通り — だから、この記事の「https://overreacted.io/progressive-json/#streaming-data-vs-s…」のセクションで、意図的に設計されたローディング状態を強調してるんだよ。
記事からの引用：＞ データがストリームされるにつれて、ページが勝手に飛び跳ねることは実は望んでいません。例えば、投稿のコンテンツなしでページを見せたくないかもしれません。だからReactは保留中のPromiseに対して「穴」を表示しません。代わりに、最も近い宣言的なローディング状態を、＜Suspense＞で示されたものとして表示します。
＞ 上の例では、ツリーに＜Suspense＞境界がありません。これは、Reactはデータをストリームとして受け取りますが、ユーザーに「飛び跳ねる」ページを実際には表示しないということです。ページ全体が準備できるまで待ちます。
しかし、UIツリーの一部を＜Suspense＞で囲むことで、段階的に表示されるローディング状態を選択できます。これはデータの送信方法を変えません（できるだけ「ストリーミング」ですが）、しかしReactがいつユーザーに表示するかを変えます。
[….]＞ つまり、UIが表示される段階は、データがどう到着するかから切り離されているということです。データは利用可能になったらストリームされますが、私たちがユーザーに表示したいのは、意図的に設計されたローディング状態に従ったものだけです。
SmalltalkのUIはCPUスレッド１つだけで動いてたんだ。ユーザーからのアクションがあるとUI全体が固まったけど、そのポジティブな側面は、それがすごく予測可能でバグがなかったことかな。SmalltalkはOOPだからそれがうまくいくんだね。
Reactは関数型プログラミングだから並列化とうまくいくし、実験の余地があるね。
＞ 特にコンテンツが飛び跳ねるやつが嫌い
これ、Androidの最初の方で覚えてるな。何か検索してクリックしようとしたら、クリックするまでに結果リストが変わって、別のものをクリックしちゃったんだ。一部のウェブサイトの広告でも起こるね、もしかしたら意図的に？
＞ ローディング中に空の状態のUIを見せる一番イライラするアンチパターン
質の低いソフトだと、検索が始まったり終わったりもしてないのに「検索結果はありません」って表示したりするよね。
SmalltalkのUIはシングルスレッドで動いてて、ユーザー操作があると処理中はUI全体が固まってたんだよね…。もしそうなら、プログラマーがGreen Threadsでミスったのかも！Smalltalk-80にはProcess、ProcessorScheduler、Semaphoreっていうマルチプロセスをサポートする3つのクラスがあるって、この本（https://rmod-files.lille.inria.fr/FreeBooks/BlueBook/Blueboo…）のp251に書いてあるよ。
「リモートデータ」パターンっていうのに興味あるかもね（もっといい名前がないんだけど）。この記事（https://www.haskellpreneur.com/articles/slaying-a-ui-antipat…）が参考になるよ。
クリックしようとしてる時にリンクとかボタンが動いちゃうよりは全然マシだよね。
あるいは、キャッシュとか他の最適化を使ってコンテンツをもっと速く提供する手もあるよ。
Emberもこれに似たことやってたけど、Ajaxエンドポイント作るのがめちゃくちゃ大変だったんだ。もうずいぶん前の話で用語は忘れちゃったけど、ファイルの最後に子要素を置いてたんだよね。DAGsを効率化するためだったと思うけど、幻覚かも。
でもSAXみたいなストリーミングパーサー使えば、初期データのロード中でも画面描画とかその後の処理を始められるかもね。
もちろんシングルスレッドVMだと、直接的なミスとかコード進化で処理順を間違えると、成功を台無しにしちゃうこともあるけど。
AIツールの呼び出しでストリーミング部分JSON応答（Progressive JSON）を本番で使ってるよ。RSCsだけじゃなくて、他にも実用的な使い道がたくさんあるって、クライアントとサーバーをじっと見てると分かるんだ。
なんでそのアプローチが役に立つのか、もっと詳しく教えてくれる？
部外者からすると、そんなに解析に時間がかかるくらい大きなJSONドキュメントを送ってるなら、子リソースを分けてフェッチするか、ページネーションを実装すべきなんじゃないかって思うんだけど。
LLMの生成が遅い時は、Progressive JSONを段階的に表示するのが絶対必要だよ。
一つのやり方は、断片が来たらすぐJSON.parseを呼ぶことだよ。引用符や閉じ括弧みたいなJSONの意味的な区切りで分割すれば、有効なオブジェクトを検知してストリーム中に処理を始められるんだ。
面白いやり方だね！共有してくれてありがとう。
元のコメンターじゃないけど、俺もPydantic AIでやったことあるよ（実際はライブラリが勝手にやってくれる）。“Streaming Structured Output”はここを見てね：https://ai.pydantic.dev/output/#streaming-structured-output
ありがとう、知ってるよ！構造化出力はllama.cppもGBNFとかJSON以外の言語でも素晴らしいサポートがあるね。GoとかRustで作ろうとしてるんだけど、JSONだけよりずっと難しいよ。持ち越すコンテキストとか状態が多いから。
Danの“2 computers”の話とか、RSCとその利点を探る最近の投稿を読んだよ。DanはReactエコシステムで最高の解説者の一人だけど、個人的には、ある技術を売り込んだり説明したりするのにこれほど頑張らなきゃいけないなら、2つの可能性が考えられる。
1/ その技術に本当の必要性がない
2/ 抽象化が欠陥だらけ
俺が知ってるほとんどのフロントエンド開発者がまだRSCを“理解”してないから、#2はある程度当たってる気がするね。Vercelはこれをユーザーに強く推してるし、RSCの採用のほとんどはNext.jsがデフォルトのReactフレームワークになってきたことによるものだよ。Next.jsユーザーの間でさえ、ほとんどの開発者はサーバーコンポーネントの境界を本当には理解してなくて、カーゴカルトになってるみたい。
さらに、ReactがViteをReactアプリを作る方法として言及するPRさえマージしようとしない事実と合わせると、RSCの全体的な推進が本当にユーザー/開発者のためなのか、それともベンダーが自分たちのホスティングプラットフォームを推し進めるためなのか、疑問に思えてくるね。S3からCDNでSPAを配信できるなら、それは明らかにVercelや世界中のNetflixみたいな企業にとっては良くないだろう。
振り返ってみると、Vercelが初代Reactチームの多くのメンバーを雇ったのは、単なる人材獲得じゃなくて、Reactの未来をコントロールするためだったのかもしれないね。
歴史的な側面や動機については間違ってるけど、今議論する気力はないし、別の投稿のために取っておくよ。（VercelがReactの方向性を決めてるわけじゃない。むしろ、Reactチームが定めた方向性の下で何人年もの作業に資金提供したのが彼らだ）。Viteについての主張だけ訂正させてくれ。作業は進んでるけど、ボールは主にViteチームのコートにあるんだ。DEVでバンドルしないとちゃんと動かないからね（そしてViteチームはそれを分かってて修正するつもりだ）。最新の進行中の作業はここにあるよ：https://github.com/facebook/react/pull/33152。
人が“理解”してない件についてだけど、君は一種の循環論法を使ってるね。それを反論するには俺が黙るしかない。でも俺は書くのが好きだし、興味深いトピックについて書きたいんだ！RSCが嫌いだったとしても、他の技術に取り入れられる面白い要素は十分にあると思う。今の時点ではそれが全てだよ。君に何かを納得させたいわけじゃなくて、人々にこれらの問題についても考えてもらって、解決策の中で好きな部分をパクってほしいんだ。ここの人たちはそれを気にしないみたいだしね。
こういう解説をしてくれてることに感謝してるよ。そうすれば、ある種の解決策（特にそれが不自然だったり複雑だったりする場合）が必要とされる問題が何なのかを理解するために遠回りしなくて済むからね。
30年近くウェブUIを作ってきた者として（怖いね…）、概して幸運なことに、使ってるフレームワークが新しい機能やパターンを導入するとき、彼らが何をしようとしてるのか分かるんだ。でも、何をしようとしてるのか分かる唯一の理由は、彼らが解決しようとしている問題にぶつかるのに時間を費やしてきたからだよ。2015年に初めてGraphQLを見たとき、俺はそれを“理解”した。10年後、GraphQLを使ってる人のほとんどは本当には理解してないんだ。なぜなら、強制されたか、新しいキラキラしたもので選んだからさ。Suspenseやserver functionsなども同じだったね。
もちろん、君が言うように静的サイトをエクスポートして基本的なCDNでホストすることは今でもできるよ。そして、デフォルトの“dynamic”モードでNext.jsをセルフホストすることもできる。Expressサーバーを動かせればいいだけで、特定のベンダーに縛られることはほとんどないね。
少し論争になるのは、stale-while-revalidateベースで動くレンダーパスのためのサーバーレス関数を使って、Next.jsをフル機能モードで動かしたい場合だ。今はVercel以外の誰もそれを適切に実装するのはとても難しい（例はopennextjsプロジェクトを見て）。非公式な“魔法”があるからね。でもありがたいことに、Next.js / Vercelは、この機能を異なるプラットフォームで一貫したAPIで実装できるようにするアダプターを実装すること（そしてドッグフードすること）を提案してるんだ：https://github.com/vercel/next.js/discussions/77740
俺はRSCへの推進が君が示唆してるような怪しい理由で全く動機づけられてるとは思わないな。SPAフレームワークが支配的になる前に僕らがウェブサイトを作っていたやり方の良いところがたくさんあったという気づきについての方が大きいと思う。ほとんどのものをサーバーでレンダリングして、クライアントでちょっとしたプログレッシブエンハンスメントを加える、というのは多くのメリットがあるパターンだ。でもSSRでも、まだクライアントに属さない多くのロジックをプッシュすることになるよね。
＞ ありがたいことに、Next.js / Vercelは、この機能を異なるプラットフォームで一貫したAPIで実装できるようにするアダプターを実装すること（そしてドッグフードすること）を提案してるんだ：
こういう取り組み（Vercelで働いてるNext.jsのメイン開発者が始めたもの）を見ると、VercelチームはReactエコシステムへの影響力を良い管理者として、そして一般的にコミュニティに有益なプレイヤーとして、正直にやろうとしてるんだって納得できるね。もちろん、VCから資金提供を受けてる会社としては自己奉仕が目的だけど、かなり立派にやってると思う。
とはいえ、プロダクションでNext.jsをサーバーの一部として動かすつもりは全くないな。太りすぎで複雑すぎるよ。Viteとその仲間みたいなもっとシンプルなものに置き換えるまでは、静的サイトジェネレーターとして使うことにするよ。
IMO、技術を売る／説明するのにこんなに苦労するなら、2つの可能性があると思うんだ。1つ目は技術自体に本当は必要がない、2つ目は欠陥のある抽象化だ。
もちろん3つ目の可能性もあるよ。解決策がその複雑さを正当化する場合だね。
難しい問題には新しい直感が必要な解決策がある。
そう簡単に言えるけど、もっと分かりやすくすべきだとも言える。
今後どうなるか見守りたいね。
RSCは技術としては面白いけど、実際にはあまり意味がないと思うな。
複雑なコンポーネントをレンダーするためにNodeやBunのバックエンドサーバーをたくさん持ちたくないんだ。
静的ページとか、GoのAPIサーバーを使ったReact SPAの方がいい。
ずっと少ないリソースで似た結果が得られるよ。
バックエンド連携に便利だよ。サーバー側でasync/await使えるし、データ読み込みにフックやコールバックいらない。
動的な表示も可能だし（権限あるメニューだけ見せるとか）、一部表示しながら他を読み込むこともできる。
良いREST APIの方がエレガントで関心分離できてるけど、フロントとバック両方メンテするのは大変だからね。
だからこれは新しいPHPみたいだ。ダッシュボードとか、複雑で高トラフィックなwebshopみたいなサイトに良いんじゃない？顧客に早く最高の選択肢を見せたい場合とかね。クロール可能で低性能デバイスでも動くべきだし。
もっとコメントを表示（1）
ページを表示するためにブラウザがAPI呼び出し（しかも相互依存してるやつもある）してる間、ユーザーがスピナーを見つめるのをどう避けるの？
それは君にとって都合が良いだけだよ。すべてのReactユーザーが君と同じじゃないし。
僕にとっては実際にすごく意味があると思うな。
RSCsは静的デプロイやSPAsでも問題なく動くよ。（Nextのサイトは全部SPAsだしね。）
ユースケースごとに最適な技術スタックがある。Isomorphic rendering（NextJS, Nuxt, Sveltekitなど）はごく一部のケースにしか合わない。
多くの”ソートリーダー”は計算が合ってない。
初回訪問時、Nextアプリは個別コンテンツを提供できないから2回往復が必要で遅い。
AstroやSolid、Svelteのような速いSPAをCDNから、データをAPIから提供する方が初回は速い。
2回目以降はNextも速いけど、CDNからのアプリはキャッシュされててさらに速い！結局個別データは1リクエストだけ。
SEOの議論もおかしい。SEOならAstroで静的HTML作ってCDNで十分。クローラーは匿名リクエストの結果を見るから静的コンテンツで良い。
99%のユースケースは、従来のサーバーレンダリングMPA（Django, ASP.NET MVC）、速いSPA（Solid, Svelte, Vue）、SEOや初速が大事なら静的サイト（Astro）の方が良いと思うな。
RSCsのコード構造を使って、HTML, CSS, JSの小さな塊に分割された静的ページをコンパイルする世界があると思う。
基本的には、記事の”$1”プレースホルダーをURIsに置き換えればサーバーは不要。（ほとんどの場合、完全な動的SSRはいらない）
大きな欠点は、コンテンツ変更時の高速なビルドや更新のために良いパイプラインが必要なこと。コンパイル済み静的サイトのS3への部分的なストリーミングとかね。（例えば数千記事ある新聞で、CMSで著者が1記事編集したらそれだけ再コンパイルしたい。でもこれにはパイプラインがコンテンツ差分をうまく扱う必要がある）
RSCはビルド時に実行できるよ。それがデフォルトだし。
だから君が言ってることとそう遠くないよ。
君の分析はすごく良いと思うし、Vercelみたいな会社がRSCを強く推してる理由にも納得だよ。
話は逸れるけど、Next.jsはかなりすごいのに、Reactを書くときのデフォルトになったのは今でも意外だよ。TypeScriptは一番好きな言語だし、Reactも大好きなんだけど、Next.jsのアプリを書くのは全然楽しくないんだよね。
参考までに言うと、僕はNext.js開発者で、うちのチームのみんなはクライアントコンポーネントとサーバーコンポーネントに結構簡単に慣れたよ。ファイルの最初にマジック文字列のコメントを書くより、Haskellみたいなモナドとか（TypeScriptでもできそう！）何か別の方法だったら良かったかなとは思うけど、少なくともうちのチームでは大した問題にはなってないみたい。
パフォーマンスでよく見るのは、数MBのデータを取ってフロントエンドで複雑な処理をしながら、ミリ秒単位のページロード時間を削ろうとする人たち。実際はBFFを書いたりアーキテクチャやAPIを改善する方が生産的だよ。GraphQLやHTTP/2で試したけど、議論の余地はあるけどうまくいかなかったね。web標準が適切に進化しないと根本的な問題は解決できないと思う。新しいフレームワークも同じだよ。
この記事の最後に説明されているRSCは、本質的にはBFF（APIロジックがコンポーネント化されたもの）だよ。このトピックに関する僕の長い記事はこちら: https://overreacted.io/jsx-over-the-wire/ （最初のセクションの途中にBFFがあるよ）
でもそれだと、かなりの複雑さと肥大化、それに運用上の欠点が増えるよね。うまく設計されたAPI（Go、ASP.NET、Javaとか）と、クライアントサイドのグローバルなデータ管理なしで、コンポーネントごとにデータ取得する速いSPA（Solidとか）の方が、シンプルで速いんじゃないかな。CDNでアプリだけじゃなくデータもキャッシュできるしね。
それは「ミリ秒単位のページロード時間を削る」ってのが何を意味するかによるんじゃないかな？
最初の描画時間とか視覚的な完了までの時間を最適化するなら、できるだけロジックを使わずにページをレンダリングする必要があるよね。空のスケルトンを送って、後からAPIでユーザーデータをハイドレートするのが、ユーザーが感じるロードの速さには一番だよ。
もし最初の入力やインタラクティブになるまでの時間を速くしたいなら、ユーザーデータを使って実際に動くページを作る必要があって、それはバックエンドの方が速いことが多いよ。ネットワーク呼び出しが一番遅い部分だからね。個人的にはほとんどのユーザーは後者の方が好きだと思うけど、アプリによるかな。CRUDみたいなSAASアプリは多分サーバーサイドレンダリングが一番だけど、Figmaみたいなのはもっと静的なページを送って、フロントエンドからユーザーデザインデータを取ってくる方が一番だよ。
何でも一つの解決策でOKって考えは間違ってるよ。何を最適化するかは主観的な選択だからね。
それに開発体験、チームの構成、Conway’s lawとか、技術選定にすごく影響する色々な要素もあるしね。
＞空のスケルトンを送って、後からAPIでユーザーデータをハイドレートするのが、ユーザーが感じるロードの速さには一番だよ
これはよく言われるけど、僕自身の経験は逆なんだよね。ページにスケルトンローダーがたくさん表示されてると、だいたい悪い体験になるなって思う。サイトが遅くてカクカクしたり問題が起きやすそうだからね。サイトでスケルトンローダーが多いほど気分が悪くなるよ。
僕の推測では、FCPがGoodhart’s Lawの犠牲になってるんじゃないかな。多くのサイトがFCPを最適化しようとする（役に立たなくても画面に何かをすぐ出すってことね）あまり、UXは最適化してないんだよ。それがレンダリングを遅らせたり、コンテンツを後からロードするためにラウンドトリップを増やしたりすることにつながる。結果として、指標上は改善してるのに、より多くのロードや複雑さでユーザー体験は悪くなってるんだよね。
Progressive JSONって、ブラウザが頑張って実装してきた最適化、例えば戻る/進むボタンの動きとかを壊しちゃうんだよね。
RedditとかとSSRのページ比べてみ？全然違うから。
まあ、失われた機能も頑張れば取り戻せるけどさ、最初にブラウザに任せときゃ良かったじゃんってくらい、追加の作業が必要になるんだよね。
企業の95%くらいは、そもそも問題作った開発者に直させるお金をケチって、新しい機能だけをせかす感じだよね。
バック/フォワードボタンもまともに動かないSPAが多すぎて、マジでひどいよ。
＞体験が向上してるって。
あれ、たぶん離脱率が改善してるだけだと思うよ。
後でヤダなと思っても、何か早く見えれば人が留まる可能性上がるから。
＞最初の表示時間とかを最適化するなら…空のスケルトンを送って後でデータ入れるのが最速って。
これ、記事の著者が言いたいのは、こういう最適化って、マルチMBのデータって根本原因を見てないってことだと思うんだよね。
複雑にしても大元がデカいと、あんま意味なくなくない？
＞最初の入力可能時間を早めるなら…バックエンドの方が速いって。
いや、それはスケルトンだけが速いんだって。
こういう2段階ロードのサイト使ってると、コンテンツが出ない、30秒待つ、ラグい、不安定、ナビ動かない、ボタン押しても反応しないとか。
マジ勘弁。凝った装飾いらないから、普通に動くサイトに戻ってくれー。
30秒は言い過ぎかもね、よっぽど回線遅くない限り。でも、他はわかるわ。
あれって2段階じゃなくて、もうn段階で読み込んでる感じだよね。
この記事読んで、Facebookのページって、なんで一番肝心なコンテンツが一番最後に表示されるのか、やっと理由が分かったよ。
Facebookのページ、俺の場合は一番肝心なコンテンツすら表示されないんだけどな…
RSC（Server Components）のデカい利点って、重いライブラリをバックエンドで使って、その出力だけをフロントに送れることだよ。
これでページ表示がマジで速くなる。
例えばSyntax Highlighter。文法とかのコードじゃなくて、整形後のHTML/CSSだけ送れる。
同じ言語で書けて、ほぼ手間なし。
もしフロントでも使いたいなら、Client ComponentにするだけでOK。
Goとかで書かれてたらヤバいよね。
BFFってのは「backend for frontend」の略だよ。
各フロントエンドが必要なAPIだけを持つ専用のバックエンドって考え方ね。
組織的に考えると最悪だよ。
バックエンドのエンジニアが、フロントエンドの流行とか実績稼ぎ開発に振り回されるんだ。
複雑さがフロントエンドからバックエンドに移るけど、それはフロントエンド側での変な選択による自作自演の複雑さだったりする。
バックエンドAPIは、ページの表示や操作に必要なデータを提供することに専念すべき。それ以外は最適化であって、必要ないかもしれないんだ。
俺も同じ疑問だったよ。
FEはフロントエンド（UI）の略ね。
BFFはBackend For Frontendの略だよ。
フロントエンドと、フロントエンドのためのバックエンドのことね。
複数のAPIをまとめたり、キャッシュしたり変換したりして、特定のページに特化したAPIを設計するのが一般的だよ。
別の考え方もあるよ。
データストリーミングはJSONが想定してる問題じゃないし、そうするべきじゃない。
もしものすごく大きなJSONを送る必要があるなら、「なんでそんな巨大なJSONを送ってるの？」って問い直すべき。
大体の場合、それはRESTを無視して、JSONを何でも屋にしようとしてる太ったクライアントのせい。
結局、データ送って、メタデータ足して、UI記述のメタデータまで足して、すごくダメなバージョンのRESTを再発明してるだけ。
解決策はJSONを変えることじゃなくて、問題の原因となる行為をやめること。多くのページに巨大なSPAフレームワークなんて必要ないんだ。
なぜこれが「問題を探してる解決策」なのか説明させて。
幅優先も一つのオプションだけど、JSONは様々な構造を持つデータ源だから、幅優先で早くレンダリングできるって保証はないんだ。
アプリはJSONの一部が必要だけど、それは単純な深さ優先や幅優先の最初の塊とは違う。
だから、JSONにURLやAPIの継続識別子を含めて、呼び出し側がどこをさらに掘り下げるか選べるようにするんだ。段階表示は、複数のリクエストに分けてデータを取ることで実現する。
JSONはオブジェクトに逆シリアル化されることが多いから、全体がないと使えない場合がある。だからやっぱり、複数のリクエストで小さいオブジェクトにするのがいい。
サーバーからJSONを取ってくるとき、普通は段階的ローディングを考えるほど大きくないはずなんだ。
HTMLは歴史的に大きくなりやすいから段階的ローディングが必要だった。それは静的だから大きな塊でロードしてキャッシュもできた。
でもJSONとそれを使うJavaScriptは状況に応じて変われる。それを使え。データを必要以上に取ってくるな。必要なものだけ読め。JSONは頻繁に変わるからキャッシュしにくいことも多い。だから大きな塊でロードしないもう一つの理由になる。
ちなみに、俺も参照を使った似たエンコーディングを持ってるけど、それは構造共有のためなんだ。俺のデータは木じゃなくてDAGみたいな形だから参照が必要でね。
幅優先エンコーディングだけど、段階的デコードは必要なかった。API層で必要なものを必要な時に正確に（またはそれに近く）リクエストすればいいからなんだ。
もっとコメントを表示（2）
＞アプリはJSONの一部が必要だけど、それは単純な深さ優先や幅優先の最初のチャンクじゃない。
そうなんだよ。
記事の終わり近くでRSCにちょっと触れてるよね。
RSCではデータがUIそのものだから、一番外側のデータが文字通り一番外側のUIに対応してるんだ。それがうまくいく理由。
Progressive JSONみたいにエンコードされるけど、考え方はHTMLに近いかな。クライアント側で独自の「タグ」を持ってて、オブジェクト属性を受け取れる感じ。
＞記事の最後の方でRSCにちょっと触れてる。
またRSCかよ、もうやめてくれ。
そして、自分の考えをより広い読者に向けて公開する上で大事なのは、読者からのフィードバックをただ切り捨てるんじゃなくて、それを評価することなんだ :)
これってもう既成事実だよね。彼らはもう全部実装済みなんだ。この段階でフィードバックを求めてるわけじゃなくて、どうやって、そしてなぜそれが動くのかを説明してる感じかな。
すごくクールな視点だね、これは一般的なツリー構造データ全般に当てはまるよ。
俺はツリーデータを親、タイプ、データそれぞれのベクトルと文字列テーブルを使って表現するのが好きで、そうすると他のものは全部小さな整数で済むんだ。
文字列テーブルとタイプ情報を最初のヘッダーとして送れば、その後には親とデータベクトルのチャンクを、まとめてNノードずつストリームで送れるんだ。
深さ優先でも幅優先でも、これはベクトルの順序次第で選べるよ。
これちょっと試してみないと！
ネットワークに負荷がかかるアプリケーションで、よりきびきびしたロード時間のUXを実現する一般的な方法になるかもね。
テーブルとノードのチャンクを交互に送ることだってできちゃうんだ！
そうすれば、親より先に子を見せるとか、任意のグラフ構造を表現するとか、どんな順序でもツリーを表示できるようになるんだよ！
いくつか面白い応用につながるかもしれないね。
いい点だね！親ベクトルの表現が任意のノード順序を可能にするんだけど、テーブルデータをノードIDのチャンクで分割するのは素晴らしいアイデアだよ。乾杯！
既知の深さでツリーを先行順巡回順序で送るなら、ノードIDや親IDなしでツリーを送れるよ！
各ノードのレベルだけを送って、スタックを使ってツリー構造を復元できるんだ。
まあ、ここでは幅優先順序を使うのが全体のポイントなんだよね。
幅優先探索に深さベクトルの類似物があるとは思わないな。あるのかな？
でも、確かに深さベクトルはきれいでコンパクトだよね。
ただ、ほとんどの場合は扱いにくいと思うんだ、特に挿入や削除が親ベクトルのO(1)に対してO(n)になるからね。
とはいえ、APIの境界では親ベクトルをdfpo順序に正規化することはよくあるよ、明確な順序があるとリーフの兄弟を見つけるみたいな特定の操作がずっと楽になるからね。
深さベクトルには詳しくないんだけど、深さ優先形式で各項目がその深さを指定するのと似た、幅優先探索の類似物って、各項目がその直下の子の数を指定することになるんじゃないかな？
うん、確かに限界はあるのは間違いないね。俺はストリーミングの側面が好きだよ。
この記事で説明されてる機能はまだ使えると思うんだ。
レベルをタグ付けした「穴」マーカーを送るんだ。
そして、復元フェーズでこれらのマーカーに遭遇したときに、おそらく穴のバッファリングをしながら追加のリクエストを出すんだよ。
これは、一度に送りたいだけツリー構造を送れる、ある種のハイブリッドなDFS/BFSアプローチになるね。
これ、小さなライブラリ作ってみる価値あるかもね。
この考え方以外に、代替案が二つあるよ。一つはJSON Linesでヘッダーとデータを分ける方法。もう一つはサーバーが属性の順序を保証して、大きな配列を最後に送る方法。これらはよくある大きなJSON問題にシンプルに対処できるし、Promiseベースよりずっと簡単だよ。
ぶっちゃけ、ほとんどのアプリにこんな高度なものはいらないでしょ。必要な情報がバラバラなら、複数回API呼べばいいんだし。今のやり方で十分だよ。
誤解しないでほしいんだけど、アプリで手動実装しろって言ってるわけじゃないんだ。これはRSCのワイヤープロトコルがどう動くかを説明してるだけ。理解の助けになったり、アイデアを組み合わせるのに役立てばいいなと思って書いたんだ。
前のコメントは別のコメントへの返信だったんだけど、消してトップに移動させたら文脈がなくなって、記事全体に対して皮肉っぽく聞こえちゃったね。それは意図してなかったよ。ごめんね。
僕が作ってるCSTML（ストリーミング形式のデータフォーマット）で、この記事のアイデアを何か取り入れられないか考えてるんだ。
複数回API呼び出しなんて嫌だね。記事のJSON例はOOP+ORM風で良くないな。コメントをID参照にする構造にするか、protobufsみたいな型付きプロトコルを使うといいかも。protobufsなら、ページの取得とコメントの取得を分けてもスッキリできるかもしれないね。
“たまたま良いオフザシェルフのオプション”があるのは全然悪くない（意図しないオーバーエンジニアリング的な意味で）。でも、既存のオプションに“fancy”な機能を追加するのは問題ありだね。それは複雑なエンジニアリング問題で、リーキーな抽象化になって結局使う人を困らせるから。
あなたのコメントは“良い結果”にフォーカスしてるけど、トレードオフの現実を見てないね。オーバーエンジニアリングは常に問題を引き起こすよ。システムは理解しにくく、メンテナンスもトラブルシューティングも大変になる。例えば、JSON配列の要素を勝手に並べ替えるツールとか、非自明な形で壊れることがあるんだ。
