仅 Json 的 Web 应用程序。有什么缺点？ （或优点）
我想设计一个Web应用程序，其唯一的接口是json，即所有http请求仅接收json格式的响应，并且不在服务器端渲染任何html。所有表单帖子都将表单数据转换为 json 对象，然后将其作为字符串发布。所有渲染均由客户端 JavaScript 完成。
我知道这种方法的一个缺点是，没有 javascript 的浏览器无法使用这种架构做太多事情，但网站上的交互足够丰富，无论如何对于非 javascript 浏览器来说毫无用处。
这种设计 Web 应用程序的方法还有其他缺点吗？
I want to design a web application whose only interface is json i.e. all the http requests receive responses only in json format and dont render any html on the server side. All the form posts convert the form data into a json object and then post it as a string. All the rendering is done by client side javascript.
The one downside of this approach I know is that browsers without javascript wont be able to do much with this architecture but the interaction on the site is rich enough to be useless to non-javascript browsers anyway.
Are there any other downsides of this approach of designing a web application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一种越来越常见的模式，使用 GWT 和 ext-js 等工具。一段时间以来，GMail 等复杂的 Web 应用程序 90% 以上都是由 JS 创建的 DOM。如果您正在开发一个传统的“期刊”类型网站，主要以书面内容供阅读，那么这种方法将是多余的。但对于希望避免页面刷新的复杂应用程序来说，这可能是合适的。
一个缺点是，它不仅需要支持 JavaScript 的浏览器，而且应用程序所需的计算资源也很容易攀升到需要功能相当强大的浏览器的地步。如果您在高端 PC 上使用 Chrome 进行开发，您可能会在功能较弱的计算机（例如上网本或移动设备）上运行该应用程序，并发现它变得相当缓慢。
另一个缺点是您在处理页面时失去了使用 HTML 工具的机会，并且在 Firebug 或 Chrome 开发人员工具下查看应用程序页面的 DOM 树可能会很困难，因为元素和代码之间的关系可能不清楚。
编辑：另一件事要考虑的是，使页面更易于访问需要更多工作，因为可能需要添加键盘快捷键（您可能无法使用此处内置的浏览器行为）并且有特殊需求的用户可能会发现更多很难改变应用程序的外观，例如通过增加字体大小。
另一项编辑：现在您网站上的文本内容不太可能被搜索引擎成功抓取。因此，您有时会看到服务器创建的纯文本页面代表相同的内容，这些页面将浏览器引向支持 JS 的页面版本。
It's an increasingly-common pattern, with tools such as GWT and ext-js. Complex web apps such as GMail have been over 90% JS-created DOM for some time. If you are developing a traditional 'journal' type website with mainly written content to be read this approach will be overkill. But for a complex app that wishes to avoid page refreshes it may well be appropriate.
One downside is that not only does it require a browser that supports JavaScript, it is also easy for the computing resources required by the app to creep up to the point where it needs quite a powerful browser. If you develop in Chrome on a top-end PC you might come to run the app on a less powerful machine such as a netbook or mobile device and find it has become quite sluggish.
Another downside is you lose the opportunity to use HTML tools when working on your pages, and that viewing your application's pages' DOM trees under Firebug or Chrome Developer Tools may be hard work because the relationship between the elements and your code may not be clear.
Edit: another thing to consider is that it is more work to make pages more accessible, as keyboard shortcuts may have to be added (you may not be able to use the browser built in behavior here) and users with special needs may find it more difficult to vary the appearance of the app, for instance by increasing font size.
Another edit: it's unlikely now text content on your website will be successfully crawled by search engines. For this reason you sometimes see server created text-only pages representing the same content, that refer browsers to the JS-enabled version of the page.
除了您指出的问题之外，还有另一个问题：速度。但这不一定是一个大问题，事实上，使用 JSON 而不是 HTML 可能（在较慢的连接上）提高而不是阻碍速度。
Web 浏览器经过高度优化，可呈现 HTML，包括整个页面（例如，通常）和片段（例如，
innerHTML及其各种包装器，如 jQuery 的html或 Prototype 的 <代码>更新）。您可以采取很多措施来最大程度地减少处理返回数据和呈现结果的速度影响，但没有什么比从服务器抓取一些 HTML 标记并将其转储到其中更快的了。浏览器进行显示。话虽如此，这并不一定会成为一个大问题。如果您使用有效的技术（本文中的一些注释），并且如果您主要通过构建 HTML 字符串来渲染结果，然后将其交给浏览器（再次通过
innerHTML或它的包装器），或者如果您一次仅渲染几个元素，不太可能有任何可察觉的速度差异。相反，如果您通过 DOM API 或包装器创建和附加单个元素来构建大量的树，您很可能会注意到性能影响。这似乎是正确的做法，但它涉及大量跨越 DOM/JavaScript 边界的行程，并且意味着浏览器必须在所有中间步骤中向代码呈现事物的 DOM 版本；相反，当你给它一个 HTML 字符串时，它可以做它的事情并全速运行它。您可以在此性能测试中看到差异。这是很重要的。
在较慢的连接上，如果 JSON 数据比 HTML 更紧凑，则速度影响可能会得到弥补甚至克服，因为线路尺寸较小。
Other than the issue you point out, there's another: Speed. But it's not necessarily a big issue, and in fact using JSON rather than HTML may (over slower connections) improve rather than hamper speed.
Web browsers are highly optimised to render HTML, both whole pages (e.g., normally) and fragments (e.g.,
innerHTMLand the various wrappers for it, like jQuery'shtmlor Prototype'supdate). There's a lot you can do to minimize the speed impact of working through your returned data and rendering the result, but nothing is going to be quite as fast as grabbing some HTML markup from the server and dumping it into the browser for display.Now, that said, it's not necessarily going to be a big problem at all. If you use efficient techniques (some notes in this article), and if you primarily render the results by building up HTML strings you're then going to hand to the brower (again, via
innerHTMLor wrappers for it), or if you're rending only a few elements at a time, it's unlikely that there will be any perceptible speed difference.If, instead, you build up substantial trees by creating and appending individual elements via the DOM API or wrappers for it, you're very likely to notice a performance impact. That seems like the right thing to do, but it involves lots of trips across the DOM/JavaScript boundary and means the browser has to present the DOM version of things to your code at all intermediate steps; in contrast, when you hand it an HTML string, it can do its thing and romp through it full-speed-ahead. You can see the difference in this performance test. It's substantial.
Over slower connections, the speed impact may be made up for or even overcome if the JSON data is more compact than the HTML would have been, because of the smaller size on the wire.
当您构建这样的东西时，您必须更加注意高延迟、低带宽连接。您可能会进行大量 Ajax 调用来同步数据并从服务器获取新数据，如果存在大量延迟，则延迟可能会很明显。您需要制定一个策略来让用户了解客户端和服务器之间的任何通信的进度。
在开发中，这一点可能会被忽视，特别是当您使用本地 Web 服务器时，但在生产中它可能是致命的。这意味着研究预取和缓存策略。
您还需要一种有效的方法来管理 HTML 片段/模板。显然，有一些用于渲染模板的好模块 - Mustache.js、Underscore 模板等 - 但保持在 HTML 片段之上可能会导致一些维护问题。我倾向于将 HTML 模板存储在单独的文件中，并通过 Ajax 调用动态加载它们（加上缓存以最大程度地减少 HTTP 请求）。
编辑 - 另一个缺点：
数据同步 - 如果您使用服务器数据库作为数据“权威”，那么保持服务器和客户端之间的数据同步很重要。如果一个客户端上的数据更改影响多个客户端，这一点就更有意义。然后，您将进入处理实时异步更新的领域，这可能会导致一些有趣的概念挑战。 （幸运的是，使用 Socket.IO 和 Backbone.js 等框架和库确实可以让事情变得更容易）。
编辑 - 优点：
这种类型的应用程序有一些巨大的优势 - 它的响应速度更快，并且可以真正增强用户体验。通常需要往返服务器并产生网络开销的琐碎操作现在可以快速、无缝地执行。
此外，它还允许您更有效地将数据耦合到您的视图。如果您在客户端处理数据，您可能会拥有一个框架，允许您组织数据并使用 ORM - 无论是 Backbone.js、Knockout.js 还是类似的框架。您不再需要担心将数据存储在 html 属性或临时变量中。一切都变得更加易于管理，并且它为一些真正复杂的 UI 开发打开了大门。
此外，JavaScript 还开启了事件驱动交互的可能性，这是高度交互应用程序的完美范例。通过使用事件循环，您可以将数据直接挂钩到用户启动的事件和自定义事件，这开辟了巨大的可能性。通过将数据模型直接连接到用户驱动的事件，您可以稳健地处理数据的更新和更改，并以最小的麻烦呈现适当的输出。而且这一切都是高速发生的。
You've got to be more mindful of high-latency, low-bandwidth connections when you're building something like this. The likelihood is, you're going to be making a lot of Ajax calls to sync data and grab new data from the server, and the lag can be noticeable if there's a lot of latency. You need a strategy in place to keep the user informed about the progress of any communication between client and server.
In development, it's something that can be overlooked, especially if you're working with a local web server, but it can be killer in production. It means looking into prefetching and caching strategies.
You also need an effective way to manage HTML fragments/templates. Obviously, there are some good modules out there for rendering templates - Mustache.js, Underscore template, etc. - but keeping on top of the HTML fragments can cause some maintenance headaches. I tend to store the HTML templates in separate files, and load them dynamically via Ajax calls (plus caching to minimise HTTP requests).
Edit - another con:
Data syncing - if you use a server database as your data "authority" then it's important to keep data in sync between the server and client. This is even more relevant if changes to data on one client affects multiple clients. You then get into the realms of dealing with realtime, asynchronous updates, which can cause some interesting conceptual challenges. (Fortunately, using frameworks and libraries such as Socket.IO and Backbone.js can really make things easier).
Edit - pros:
There are some huge advantages to this type of application - it's far more responsive, and can really enhance the user experience. Trivial actions that would normally require a round-trip to the server and incur network overhead can now be performed quickly and seamlessly.
Also, it allows you to more effectively couple data to your views. Chances are, if you're handling the data on the client-side, you will have a framework in place that allows you to organise the data and make use of an ORM - whether its Backbone.js, Knockout.js or something similar. You no longer have to worry about storing data in html attributes or in temporary variables. Everything becomes a lot more manageable, and it opens the door for some really sophisticated UI development.
Also also, JavaScript opens up the possibility for event-driven interaction, which is the perfect paradigm for highly interactive applications. By making use of the event loop, you can hook your data directly to user-initiated and custom events, which opens up great possibilities. By hooking your data models directly to user-driven events, you can robustly handle updates and changes to data and render the appropriate output with minimal fuss. And it all happens at high speed.
我认为最重要的是你的要求是什么，如果你想构建一个交互式应用程序，给人桌面般的感觉，那么就去客户端开发。使用像backbone.js 或knockout.js 这样的Javascript 框架将真正有助于组织和维护代码。优点在前面的答案中已经详细说明。至于服务器端渲染的渲染性能，这里有一篇很好的博客文章，它引起了思考。
http://openmymind.net/2012/5/ 30/客户端与服务器端渲染/
I think the most important thing is what is your requirement, if you want to build a interactive application, giving desktop like feel then go for client side development. Using Javascript framework like backbone.js or knockout.js will really help in organizing and maintaining the code. The advantages are already detailed out in previous answers. As respect to the performance in rendering with respect to server side rendering is concerned here is a nice blog post which made thinking.
http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/