18

我正在开发一个需要开始缓存内容的应用程序，这让我开始思考......

  1. 在应用程序的某些部分，我通过抓取纯 JSON 并通过诸如 Mustache、jquery.tmpl 等运行它来呈现表行（jqGrid、slickgrid 等）或花哨的 div 行（如在 New Twitter 中）。
  2. 在应用程序的其他部分，我只是在纯 HTML（服务器端 HAML 模板）中呈现信息，如果有搜索/分页，我只需转到一个新 URL 并加载一个新 HTML 页面。

现在问题在于缓存和可维护性。

一方面我在想，如果一切都是使用 Javascript HTML 模板构建的，那么我的应用程序将只提供一个 HTML 布局/shell 和一堆 JSON。如果您查看 Facebook 和 Twitter HTML 源代码，那基本上就是他们正在做的事情（95% json/javascript，5% html）。这将使我的应用程序只需要缓存 JSON（页面、操作和/或记录）。这意味着无论您是访问 JSON api 的远程 api 开发人员还是海峡网络应用程序，您都会访问缓存。也就是说，我不需要 2 个缓存，一个用于 JSON，一个用于 HTML。这似乎将我的缓存存储减少了一半，并简化了一些事情。

另一方面，我认为，从我所见/经历的情况来看，生成静态 HTML 服务器端并对其进行缓存似乎是跨浏览器性能更好的；您可以立即获得图形，而不必等待 JavaScript 渲染它的那一瞬间。StackOverflow 似乎用纯 HTML 做所有事情，谷歌也是如此，你可以说......一切都立即出现。请注意，尽管在twitter.com上，页面是空白的 0.5-1 秒，并且页面块在：javascript 必须呈现 json。这样做的缺点是，对于任何动态的东西（比如无限滚动或网格），无论如何我都必须创建 javascript 模板......所以现在我有服务器端 HAML 模板、客户端 javascript 模板等等更多缓存。

我的问题是，对于如何处理这个问题是否有任何共识？从您将两者混合而不是 100% 与另一种混合的经验中，有哪些优点和缺点？

更新：

我还没有决定使用 100% javascript 模板的一些原因是：

  • 性能。尚未正式测试，但据我所见，原始 html 比 javascript 生成的 html 跨浏览器呈现更快、更流畅。另外，我不确定移动设备如何处理动态 html 性能。
  • 测试。我有很多与静态 HTML 配合良好的集成测试，因此切换到仅 javascript 需要 1) 更专注的纯 javascript 测试 ( jasmine )，以及 2) 将 javascript 集成到 capybara 集成测试中。这只是时间和工作的问题，但它可能很重要。
  • 维护。摆脱 HAML。我喜欢 HAML，它很容易编写，它打印出漂亮的 HTML……它使代码干净，它使维护变得容易。使用 javascript，没有什么比这更简洁了。
  • 搜索引擎优化。我知道 google 处理 ajax /#!/path，但还没有掌握这将如何影响其他搜索引擎以及旧版浏览器如何处理它。似乎需要进行大量设置。
4

3 回答 3

8

持久的私有数据存储。

您需要一台服务器来存储具有各种公共/私人访问级别的数据。您还需要一个服务器来获取安全的闭源信息。您需要一台服务器来完成您不想在客户端上做的繁重工作。复杂的数据查询最好留给您的数据库引擎。索引和搜索尚未针对 javascript 进行优化。

此外，您还遇到旧浏览器速度慢得多的问题。如果您没有运行 FF4/Chrome 或 IE9，那么客户端和服务器上的数据操作和页面构建之间存在很大差异。

我自己将尝试构建一个完全使用 MVC 框架和模板制作的 Web 应用程序，但仍使用服务器连接到安全和优化的数据库。

但总的来说，该应用程序确实可以完全使用 javascript 并使用模板构建。各种构造和 javascript 引擎已经足够先进，可以做到这一点。有足够多的流行框架可以做到这一点。Pure javascript Web 应用程序不再是实验和原型。

哦，如果要为此推荐框架，那么请看一下主干.js。

安全

我们不要忘记我们不信任客户。我们需要服务器端验证。JavaScript 是解释性的、动态的并且可以在运行时进行操作。我们从不相信客户的意见。

于 2011-03-06T19:40:07.037 回答
5

我曾经混合使用这两种方法，但后来完全切换到客户端渲染，因为否则很难正确处理繁重的 JavaScript。作为一个完整的解决方案可以推荐JavaScriptMVC框架的方法。

它有一个名为 EJS 的视图渲染引擎，它可以将您的视图压缩为纯 JavaScript 以用于您的应用程序的生产构建。这使得它非常快（您的所有 HTML 都使用单个压缩的 JavaScript 文件预加载，因此在您收到模型 JSON 数据后立即呈现）。我个人没有注意到 EJS 渲染和传输纯 HTML 之间的性能差异。

然后对于您的 API，遵循 REST 原则，缓存是关键约束之一。因此，如果您的应用程序为 JSON 数据正确支持 HTTP 缓存并使用压缩的客户端模板，您甚至可能会看到性能提升。

于 2011-03-06T19:44:42.787 回答
2

我可能会离开这里，但是...

你看过 CouchDB 吗？（顺便说一句，我与他们没有从属关系）我可能错了，但你的情况听起来可能非常适合使用Apache CouchDB我自己还没有真正使用过它，但我好好看看不久前，它是一个非常有趣的数据库。

它是一个基于文档的数据库，使用 REST api 进行连接（非常通用且易于使用）。它也非常以 JSON 为中心，速度非常快且占用空间很小；他们说它也可以驻留在手机和其他嵌入式用途上，但同时应该具有极强的可扩展性（即向上）。如果您是 JS 的大用户（听起来像您），那么您可能就对它了如指掌。

我只是想它可能会以这里提出的任何方式派上用场，并认为我会插话只是为了给你一个关于存储选项的想法:)

于 2011-03-06T20:26:24.613 回答