理論的には、新しい rAppid.js サーバーを使用してそこでテンプレートをレンダリングし、レンダリングされた HTML をクライアントに送信できますか?
はい、ノード レンダリング機能を使用します。ただし、ノード レンダリングは SEO の理由で開発されたことに注意してください。この背景のため、アプリケーションの唯一の状態は URL です。これは、ユーザーのニュースをレンダリングするアプリケーションの概念 (例: /user/{userid}/news) に適合しますが、レンダリングされたサイトは完全に静的になります。
したがって、ユーザー入力、クライアント側の検証を中継する場合は、設計どおりに rAppid:js を使用し、完全なアプリケーションをクライアントでレンダリングする必要があります。
ページをできるだけ早くロードし、アプリをオフラインで動作させる必要がないことを考えると、サーバー側でテンプレートをレンダリングし、プレーンな HTML としてクライアントに送信することをお勧めします。明らかに、この場合、フレームワークは一方向のデータ バインディングしか提供できません (Derby フレームワークと同様にサーバー レンダリング モデルをサポートするために rAppid.js コードを作り直さない限り) が、アプリのパフォーマンスは次のように改善される可能性があると思います。価値がある。
RIA での私の経験では、最初の読み込みフェーズがあり (Flex アプリケーションはローダーを表示し、iOS ネイティブ アプリケーションはアプリの準備ができるまでイメージを表示します)、アプリは追加の読み込み時間なしですばやく動作します。アプリケーションをモジュールに分割し (rAppid.js はこれを非常によくサポートします)、必要な起動時にモジュールをロードするだけで、アプリケーションは非常に高速にロードされます。アプリを Web ビュー内にラップすると、JS のパフォーマンスは、モバイル ブラウザー内で実行するよりもわずかに向上します。
サーバー側とクライアント側のレンダリングを組み合わせて試すこともできますが、それらを混在させることはできません。そのため、サーバー上でページをレンダリングし、アプリケーションの読み込み段階で静的 html を表示します。アプリケーションが完全に読み込まれている限り、ビューを切り替えます。
モバイル デバイスでの rAppidJS のクライアント側のレンダリング速度について、私は過度に悲観的になっているかもしれませんが、いずれにせよ、これに関する意見を聞きたいと思っています。
最新のプロジェクトでは、プリローダーも追加し、プロジェクトをモジュールに分割しました。フラッシュ バージョンと比較すると、10 分の 1 のサイズで、デスクトップ システムでの読み込みが高速です。モバイルではフラッシュプラグインが原因でロードされないため、比較できません。
モバイル デバイスで優れたパフォーマンスが必要な場合は、アプリケーションをいくつかのモジュールに分割し、必要な場合にのみロードします。
rAppid:js はルートに基づくモジュールのロードをサポートしているため、事前に選択されたモジュールでアプリケーションを起動することもできます。