这可能非常愚蠢，但我不能怀疑，在 ember 中，我们使用 javascript 的车把模板编写所有 HTML，所以如果我有 n 个不同的页面，那么我会说 n 个车把模板，每个模板也是一个对象（我使用了构建工具，所以我有这个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 应用程序之间来回切换。也许是一个处理登录、营销、查看内容等的“公共”应用程序和一个处理后端帐户页面的“私人”应用程序。