为什么我不直接使用Javascript和Javascript HTML模板构建整个Web应用程序？

Question

我正在开发一个应用程序，在其中需要开始缓存一些东西，这让我深思...

1. 在应用程序的某些部分中，我通过获取纯JSON并运行Mustache、jquery.tmpl等组件来生成表格行(jqGrid、slickgrid等)或新Twitter中的漂亮div行。
2. 在应用程序的其他部分中，我只是以纯HTML方式呈现信息(服务器端HAML模板)，如果有搜索/分页，我只需转到新的URL并加载新的HTML页面。

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

一方面，我认为，如果使用JavaScript HTML模板构建所有内容，那么我的应用程序将仅提供HTML布局/外壳和一堆JSON。如果查看Facebook和Twitter的HTML源代码，基本上就是他们做的事情(95% json/javascript，5% html)。这将使得我的应用程序只需要缓存JSON(页面、操作和/或记录)。这意味着无论你是远程API开发人员访问JSON API还是直接在Web应用程序中，你都会命中缓存。也就是说，我不需要两个缓存，一个用于JSON，另一个用于HTML。这似乎可以将我的缓存存储减少一半，并稍微简化一下事情。

另一方面，我认为，就跨浏览器性能而言，生成静态HTML服务器端并对其进行缓存似乎要好得多；你可以立即获得图形，无需等待JavaScript渲染它。StackOverflow似乎在纯HTML中执行所有操作，Google也是如此，您可以看到...所有内容都会一次性出现。请注意，在twitter.com上，页面空白了0.5-1秒钟，然后页面变成块状: JavaScript必须渲染JSON。这样做的缺点是，对于任何动态内容(如无限滚动或网格)，我仍然需要创建JavaScript模板...因此现在我有服务器端HAML模板、客户端JavaScript模板和更多要缓存的内容。

我的问题是，是否有关于如何处理这个问题的共识？根据你的经验，混合使用两种方法与完全只使用其中一种方法相比，有哪些利弊？

更新：

以下是我还没有决定完全采用JavaScript模板化的原因：

• 性能。尽管我没有进行正式测试，但从我所见，原始HTML在跨浏览器上呈现速度更快、更流畅，而使用JavaScript生成的HTML则不确定移动设备在性能方面如何处理。
• 测试。我有很多集成测试可以很好地与静态HTML配合使用，因此仅使用JavaScript需要1）更加专注的纯JavaScript测试（jasmine），以及2）将JavaScript集成到capybara集成测试中。虽然这只是时间和工作量的问题，但它可能是显著的。
• 维护。摆脱HAML。我喜欢HAML，它很容易编写，打印出漂亮的HTML...它使代码变得干净，维护也很容易。使用JavaScript，没有任何一种方法能够如此精简。
• SEO。我知道Google处理ajax /#!/path，但还没有掌握其他搜索引擎如何处理它以及旧版浏览器如何处理它的问题。似乎需要进行重要的设置。

- Lance

---

你可能已经注意到 Twitter 页面的加载速度非常快，几乎是瞬间完成，而不需要等待 0.5-1 秒钟。无论是等待浏览器还是 JavaScript 加载，都几乎没有什么区别。 - Raynos

好问题。阅读答案将会很有趣。如果性能至关重要，我会采用静态HTML和模板的混合方法。 - jimmystormig

更新。已完成 http://towerjs.org 网站。现在我使用 JavaScript 和 JavaScript 模板来构建整个应用程序。 - Lance

Answer 1

持久化私有数据存储。

您需要一个服务器来存储具有不同级别的公共/私有访问权限的数据。您还需要一个服务器来存储安全的闭源信息。您需要一个服务器来完成客户端不想做的繁重工作。复杂的数据查询最好由您的数据库引擎处理。索引和搜索尚未针对JavaScript进行优化。

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

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

但总的来说，应用程序确实可以完全使用JavaScript和模板构建。各种构造和JavaScript引擎已经足够先进。有足够流行的框架可供使用。纯JavaScript Web应用程序不再是实验和原型。

哦，如果我们要为此推荐框架，请看一下backbone.js。

---

安全性

---

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

- Raynos

---

我目前正在开发一个JavaScript视图生成器，它从DB REST API层以JSON格式提取数据。非常有趣的事情。 - Evan Plaice

Answer 2

我曾经混合使用这两种方法，但后来完全转向客户端渲染，因为要正确处理重型JavaScript非常困难。作为一个完整的解决方案，我可以推荐JavaScriptMVC框架的方法。

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

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

- Daff

---

很好，我一直在Rails中使用coffeescript的coffeekup，它与erb相比几乎具有相同的功能，但类似于haml。不过，在这个问题中，我更多地寻求框架无关的策略，因为我仍然需要创建基本重复的服务器端和客户端模板。 - Lance

我认为将模板压缩/编译成纯JavaScript并提供一致的REST API而不是框架无关的方法很好。我发现JavaScriptMVC是一个处理你所要求的问题的最佳解决方案（顺便说一下，还有一个coffeescript视图插件;)。我可以摆脱整个服务器端视图，并同时实现更好的前后端分离。 - Daff

Answer 3

我可能完全错了，但是...

你是否看过CouchDB？（我不是他们的成员）。我可能错了，但你的情况听起来它可能非常适合使用Apache CouchDB。虽然我自己并没有真正使用过它，但我曾经仔细地研究过它，发现这是一个非常有趣的数据库。

它是基于文档的数据库，使用REST API进行连接（非常灵活和易于使用）。它也非常注重JSON，速度非常快，占用空间很小；他们说它可以适应手机和其他嵌入式用途，同时也极具可扩展性（向上扩展）。如果你是一个大型JS用户（就像你听起来的那样），那么你可能会对它感到非常满意。

我只是想着它可能在此提出的任何一种方式中都会有所帮助，所以我想插一句话，给你提供一些存储选项的想法 :)

- rhaag71