为啥我不直接在 Javascript 和 Javascript HTML 模板中构建整个 Web 应用程序？

Posted 2023-03-05

【中文标题】为啥我不直接在 Javascript 和 Javascript HTML 模板中构建整个 Web 应用程序？

【英文标题】：Why don't I just build the whole web app in Javascript and Javascript HTML Templates?为什么我不直接在 Javascript 和 Javascript HTML 模板中构建整个 Web 应用程序？

【发布时间】：2011-07-09 22:19:49

【问题描述】：

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

在应用程序的某些部分，我通过抓取纯 JSON 并通过 Mustache、jquery.tmpl 等运行它来呈现表格行（jqGrid、slickgrid 等）或花哨的 div 行（如在新 Twitter 中） . 在应用程序的其他部分，我只是以纯 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 渲染它的那一瞬间。 *** 似乎用纯 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，但还没有掌握这将如何影响其他搜索引擎以及旧浏览器如何处理它。似乎需要进行大量设置。

【问题讨论】：

您已经注意到 twitter 页面会立即加载，而不是需要 0.5-1 秒才能加载。加载是等待浏览器还是等待 javascript 几乎没有区别。

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

更新。制作towerjs.org。我现在用 JavaScript 和 JavaScript 模板构建整个应用程序。

【参考方案1】：

永久私有数据存储。

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

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

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

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

哦，如果要为此推荐框架，请查看backbone.js。

---

安全

---

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

【讨论】：

我目前正在开发一个 JavaScript 视图生成器，它从 DB REST API 层提取 JSON 格式的数据。有趣的东西。

【参考方案2】：

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

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

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

【讨论】：

很好，我一直在 Rails 中使用 coffeekup 和 coffeescript，做的事情几乎相同，但它类似于 haml 而不是 erb。我更多的是寻找与框架无关的策略，尽管在这个问题 b/c 中我仍在创建基本上重复的服务器端和客户端模板。

我发现将模板压缩/编译为纯 JavaScript 并提供一致的 REST api 而不是框架无关的方法。我刚刚发现 JavaScriptMVC 是一个一致的解决方案的最佳示例，它可以准确地处理您所要求的内容（顺便说一句，还有一个咖啡脚本视图插件；）。我可以摆脱整个服务器端视图，同时更好地分离前端和后端。

【参考方案3】：

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

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

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

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