これは非常に初心者かもしれませんが、私はこの疑いを抱くことができませんでした.emberでは、javascriptであるハンドルバーテンプレートを使用してすべてのHTMLを記述しています. （ビルドツールを使用したのでEmber.TEMPLATES、すべてのテンプレートを保存するこのハッシュがあります）
より多くのテンプレート =>Ember.TEMPLATESハッシュのより多くのプロパティ => 私の App.js はサイズが大きくなり、そのハッシュを保持するために多くのメモリが使用されます
最初の疑問は、JavaScript 全体を一度に出荷しているため、アプリケーションの読み込み時間が長くなることです。プラスの点は、読み込まれると Web アプリケーションの相互作用がはるかに高速になることです。
また、ハッシュを保持するために多くのメモリが使用されるため、Web アプリケーションは多くのリソースを使用します。
まず、私の仮定に何か問題がありますか？そうでない場合、多くのインタラクティブな Web アプリケーションを使用するために支払う代償でしょうか?
それはすべて、他のリソースをロードする方法に依存すると思います。はい、JavaScript は、クライアントに組み込まれていない Web アプリケーションの JavaScript よりも読み込みに時間がかかります。
ただし、この読み込み時間は、ユーザーがアクセスする各ページで別の HTTP 要求が作成されるため、JavaScript を何度も再読み込みする必要がある「通常の」アプリの「合計」読み込み時間よりも大幅に短いことに注意してください。
また、Ember は非同期であるため、他の外部リソース (画像、データなど) を最初に読み込まないようにアプリを設計し、DS.Store メカニズムを使用してそれらを取り込むことができるため、初期読み込み時間を短縮できます。 JS/HTML/CSS とその他すべてを後で取得できます (サーバーで高価なデータベース クエリを待つ必要はもうありません)。
そうです、Ember は JavaScript の初期ロード時間の短縮に匹敵しますが、アプリの合計ロード時間を短縮するツールを提供します。
ブラウザ リソースに関しては、Ember は非常に効率的ですが、より多くのブラウザ メモリを使用することは、独自のサーバーではなくクライアントのマシンで計算を実行するために支払う代償にすぎません。最新のブラウザーとマシンのほとんどは、この余分なリソース要件を処理するのに十分な性能を備えているため、トレードオフに見合うだけの価値があるという考えです。
編集：
何をしても、アプリが大きすぎてブラウザが処理できない可能性があります (ただし、そのためにはアプリがかなり大規模である必要があります)。その場合に対処する方法は、複数の Ember アプリに分割して、ユーザーが Ember アプリ間を行き来するのを最小限に抑えることです。おそらく、ログイン、マーケティング、コンテンツの表示などを処理する「パブリック」アプリと、バックエンド アカウント ページを処理する「プライベート」アプリです。