Javascript 仅Json的web应用程序。缺点是什么？（或专业人士）

我想设计一个web应用程序，它的唯一接口是json，即所有http请求只接收json格式的响应，不在服务器端呈现任何html。所有表单post都将表单数据转换为json对象，然后将其作为字符串发布。所有渲染都由客户端javascript完成

我知道这种方法的一个缺点是，没有javascript的浏览器无法使用这种体系结构，但是站点上的交互非常丰富，对非javascript浏览器来说毫无用处

---

这种设计web应用程序的方法还有其他缺点吗？

除了您指出的问题之外，还有另一个问题：速度。但这不一定是个大问题，事实上，使用JSON而不是HTML（通过较慢的连接）可以提高而不是阻碍速度

Web浏览器经过高度优化，可以呈现HTML，包括整个页面（例如，正常情况下）和片段（例如，

innerHTML

以及各种包装，如jQuery的

HTML

或Prototype的

更新

）。为了最大限度地降低处理返回数据和呈现结果的速度影响，您可以做很多事情，但没有什么比从服务器获取一些HTML标记并将其转储到浏览器中显示更快的了

这就是说，这不一定会成为一个大问题。如果您使用高效的技术（一些注释），并且如果您主要通过构建HTML字符串来呈现结果，那么您将把结果交给浏览器（同样，通过

innerHTML

或包装器），或者如果您一次只呈现几个元素，则不太可能有明显的速度差异

相反，如果通过domapi或其包装器创建和附加单个元素来构建大量的树，则很可能会注意到性能影响。这似乎是正确的做法，但它涉及到许多跨DOM/JavaScript边界的旅行，这意味着浏览器必须在所有中间步骤向您的代码呈现事物的DOM版本；相反，当你给它一个HTML字符串时，它可以完成它的任务并全速前进。你可以从中看出区别。这是实质性的

---

在较慢的连接中，如果JSON数据比HTML更紧凑，则速度影响可能会得到弥补，甚至会被克服，因为网络上的大小更小。

这是一种越来越常见的模式，使用GWT和ext js等工具。一段时间以来，GMail等复杂的web应用程序90%以上是由JS创建的DOM。如果你正在开发一个以书面内容为主的传统“期刊”型网站，那么这种方法就太过分了。但对于一个希望避免页面刷新的复杂应用程序来说，这可能是合适的

一个缺点是，它不仅需要一个支持JavaScript的浏览器，而且应用程序所需的计算资源也很容易达到需要一个功能强大的浏览器的程度。如果你在一台高端PC上使用Chrome开发，你可能会在一台功能较弱的机器（如上网本或移动设备）上运行该应用程序，并发现它变得相当缓慢

另一个缺点是，在处理页面时，您将失去使用HTML工具的机会，并且在Firebug或Chrome Developer工具下查看应用程序页面的DOM树可能是一项艰巨的工作，因为元素与代码之间的关系可能不清楚

编辑：另一个需要考虑的是，让页面更容易访问的是更多的工作，因为可能需要添加键盘快捷键（可能无法使用这里内置的浏览器），特别需要的用户可能会发现改变应用程序的外观更困难，例如通过增加字体大小。

---

另一个编辑：现在你网站上的文本内容不太可能被搜索引擎成功抓取。因此，有时您会看到服务器创建的纯文本页面表示相同的内容，这些页面将浏览器指向支持JS的页面版本。

在构建类似内容时，您必须更加注意高延迟、低带宽的连接。可能的情况是，您将进行大量Ajax调用以同步数据并从服务器获取新数据，如果存在大量延迟，则延迟可能很明显。您需要一个适当的策略，让用户了解客户端和服务器之间的任何通信的进度

在开发中，这是一个可以忽略的问题，特别是当您使用本地web服务器时，但在生产中它可能是杀手锏。这意味着研究预取和缓存策略

您还需要一种有效的方法来管理HTML片段/模板。显然，有一些很好的模块用于呈现模板——Mustache.js、下划线模板等——但保持HTML片段的顶部会导致一些维护问题。我倾向于将HTML模板存储在单独的文件中，并通过Ajax调用动态加载它们（加上缓存以最小化HTTP请求）

编辑-另一个缺点：

数据同步-如果您使用服务器数据库作为数据“权限”，则保持服务器和客户端之间的数据同步非常重要。如果一个客户机上的数据更改影响多个客户机，则这一点更为重要。然后进入处理实时、异步更新的领域，这可能会带来一些有趣的概念挑战。（幸运的是，使用Socket.IO和Backbone.js等框架和库确实可以让事情变得更简单）

编辑-优点：

这种类型的应用程序有一些巨大的优势——它的响应速度快得多，并且可以真正增强用户体验。通常需要往返服务器并产生网络开销的琐碎操作现在可以通过quickl执行