Javascript のパフォーマンスに関する電子メール リストから興味深い記事を見つけました。記事中のテクニックの名前や言い回しが思い出せず、その電子メールはとうの昔になくなってしまいました。
この記事で提案されているアイデアは、Web ページで実行される簡単で些細なタスク (ステータス更新の投稿、アンケートへの投票、賛成/反対の評価など) が瞬時に実行されるように見えるべきだというものです。これを実現するには、AJAX リクエストが成功すると想定し、ユーザーがアクションを完了したらすぐに、ページに視覚的な変更を加えて成功を示します (ステータス更新の追加、投票結果の表示など)。
この手法は「推定 JavaScript」または「疑似パフォーマンスの何かまたはその他」のようなものと呼ばれていると思いましたが、これらの検索では探しているものが返されません。皆さん、私が何について話しているか分かりますか? 役に立つ記事への良いリンクはありますか?
あなたが言及しているのは、もともと「Asynchronous User Interfaces」（AUI）と名付けたAlex McCawによるブログ投稿のようです。
http://blog.alexmaccaw.com/asynchronous-ui
マルチプレイヤー ゲームで使用される手法に言及してジョセフが投稿した返信は、実際には「推測航法」と呼ばれています。56k のダイヤルアップ モデムを使用していた 1990 年代には、リアルタイムのマルチプレイヤー ゲームでは遅延が深刻な問題でした。遅延を隠すために、予測された方向、速度などに基づいてプレイヤーのパスが推定される「推測航法」が Quake などのゲームに導入されました。
この専門用語を使用した当時の記憶にある記事を次に示します。
推測航法は今日でも使用されています。このイノベーションは主に、補間よりも外挿を使用することに関係していました。パケットが到着するのを待って補間するのではなく (これは常に実際のイベントの背後にあります)、外挿を使用して、プレーヤーまたはオブジェクトがどこにあるかを予測しようとします。ただし、実際のイベントは予測を「置き換える」ものではありません。以前の予測が間違っていた場合、プレーヤーまたはオブジェクトを正しい新しい位置に単に「テレポート」するのではなく、到着した新しいデータを使用して、より正確な新しい予測を作成しようとします。
同じ原則を UI 設計にも適用する必要があります。最良の予測を提供するように非同期 UI を設計するにはどうすればよいでしょうか? 予測が失敗した場合、どうすれば「テレポート」を回避できますか? たとえば、世論調査で、予測された世論調査の結果を提供していて、予測がかなり外れていて、その後、大幅に異なる結果を提供して予測を「修正」した場合、「修正」が到着したときにユーザーを混乱させるだけです。 . ここでは創造性次第ですが、ポーリングの例での「プリフェッチ」などの既存の手法を使用できます。
うーん、ゲームの「ラグ/レイテンシ補正」に似ているように聞こえます。コンピューターは、次に何が起こるかを (自信を持って) 予測することによって補正します。実際に起こることが予測と矛盾する場合、実際の出来事が予測に取って代わります。
Meteorフレームワークもこの手法を使用します。