服务器端处理与客户端处理 +阿贾克斯？
寻找一些一般性建议和/或想法...
我正在创建我认为更像是一个网络应用程序而不是网页，因为我希望它像一个 Gmail 应用程序，您可以在其中整天打开页面同时将更新“推送”到页面（对于感兴趣的我正在使用彗星编程技术）。我以前从未创建过如此丰富的 ajax 和 javascript 网页（我现在是 jquery 的忠实粉丝）。因此，当我一次又一次地实现一个需要服务器需要了解的 UI 动态更改的新功能时，我面临着同样的问题：
1）我应该在服务器上进行所有处理吗？ javascript 中的客户端并通过 ajax 尽可能少地回发 或者 2）我应该通过ajax向服务器发送请求，让服务器完成所有处理，然后发回新的html。然后在ajax响应上我用新的HTML做了一个简单的分配，
我一直倾向于遵循#1。我想这个网络应用程序可能会对所有 ajax 请求变得非常健谈。我的想法是尽可能减少请求和响应的大小，并依靠不断改进的 javascript 引擎来完成尽可能多的处理和 UI 更新。我发现使用 jquery 我可以在客户端做很多以前无法轻松完成的事情。我的 JavaScript 代码实际上比我的服务器端代码更大、更复杂。我还需要执行一些简单的计算，我也将其推送到客户端。
我想我的主要问题是，我们是否应该尽可能努力进行客户端处理而不是服务器端处理？我一直觉得服务器处理的事情越少，可扩展性/性能就越好。让客户端处理器的能力来完成所有艰苦的工作（如果可能的话）。
想法？
looking for some general advice and/or thoughts...
i'm creating what i think to be more of a web application then web page, because i intend it to be like a gmail app where you would leave the page open all day long while getting updates "pushed" to the page (for the interested i'm using the comet programming technique). i've never created a web page before that was so rich in ajax and javascript (i am now a huge fan of jquery). because of this, time and time again when i'm implementing a new feature that requires a dynamic change in the UI that the server needs to know about, i am faced with the same question:
1) should i do all the processing on the client in javascript and post back as little as possible via ajax
or
2) should i post a request to the server via ajax, have the server do all the processing and then send back the new html. then on the ajax response i do a simple assignment with the new HTML
i have been inclined to always follow #1. this web app i imagine may get pretty chatty with all the ajax requests. my thought is minimize as much as possible the size of the requests and responses, and rely on the continuously improving javascript engines to do as much of the processing and UI updates as possible. i've discovered with jquery i can do so much on the client side that i wouldn't have been able to do very easily before. my javascript code is actually much bigger and more complex than my serverside code. there are also simple calulcations i need to perform and i've pushed that on the client side, too.
i guess the main question i have is, should we ALWAYS strive for client side processing over server side processing whenever possible? i 've always felt the less the server has to handle the better for scalability/performance. let the power of the client's processor do all the hard work (if possible).
thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
在决定是否应在服务器端或客户端构建由 ajax 请求创建的新 HTML 片段时，需要考虑几个因素。需要考虑的一些事项：
性能。你的服务器必须做的工作就是你应该关心的。通过在客户端进行更多处理，可以减少服务器的工作量并加快速度。例如，如果服务器可以发送一小段 JSON 而不是巨大的 HTML 片段，那么让客户端执行此操作会更有效。在以任一方式发送少量数据的情况下，差异可能可以忽略不计。
可读性。在 JavaScript 中生成标记的缺点是阅读和维护代码更加困难。在语法着色设置为 JavaScript 的文本编辑器中，在带引号的字符串中嵌入 HTML 看起来很糟糕，并且使编辑变得更加困难。
数据、表示和行为的分离。就可读性而言，在 JavaScript 中包含 HTML 片段对于代码组织来说没有多大意义。 HTML 模板应该处理标记，而 JavaScript 应该单独处理应用程序的行为。插入到页面中的 HTML 片段的内容与您的 JavaScript 代码无关，只与它的插入位置、插入时间相关。
出于上面提到的可读性和代码组织原因，在处理 ajax 响应时，我更倾向于从服务器返回 HTML 片段。当然，这一切都取决于您的应用程序如何工作、ajax 响应的处理强度以及应用程序获得的流量。如果服务器在生成这些响应时必须做大量工作并导致瓶颈，那么将工作推送给客户端并放弃其他考虑可能更重要。
There are several considerations when deciding if new HTML fragments created by an ajax request should be constructed on the server or client side. Some things to consider:
Performance. The work your server has to do is what you should be concerned with. By doing more of the processing on the client side, you reduce the amount of work the server does, and speed things up. If the server can send a small bit of JSON instead of giant HTML fragment, for example, it'd be much more efficient to let the client do it. In situations where it's a small amount of data being sent either way, the difference is probably negligible.
Readability. The disadvantage to generating markup in your JavaScript is that it's much harder to read and maintain the code. Embedding HTML in quoted strings is nasty to look at in a text editor with syntax coloring set to JavaScript and makes for more difficult editing.
Separation of data, presentation, and behavior. Along the lines of readability, having HTML fragments in your JavaScript doesn't make much sense for code organization. HTML templates should handle the markup and JavaScript should be left alone to handle the behavior of your application. The contents of an HTML fragment being inserted into a page is not relevant to your JavaScript code, just the fact that it's being inserted, where, and when.
I tend to lean more toward returning HTML fragments from the server when dealing with ajax responses, for the readability and code organization reasons I mention above. Of course, it all depends on how your application works, how processing intensive the ajax responses are, and how much traffic the app is getting. If the server is having to do significant work in generating these responses and is causing a bottleneck, then it may be more important to push the work to the client and forego other considerations.
我目前正在开发一个计算量很大的应用程序，并且几乎所有内容都在客户端渲染。我不知道您的应用程序将要做什么（更多详细信息会很好），但我想说您的应用程序可能会做同样的事情。只需确保所有与安全和数据库相关的代码都位于服务器端，因为不这样做会在应用程序中打开安全漏洞。以下是我遵循的一些一般准则：
I'm currently working on a pretty computationally-heavy application right now and I'm rendering almost all of it on the client-side. I don't know exactly what your application is going to be doing (more details would be great), but I'd say your application could probably do the same. Just make sure all of your security- and database-related code lies on the server-side, because not doing so will open security holes in your application. Here are some general guidelines that I follow:
我最近遇到了同样的问题，决定使用浏览器端处理，在 FF 和 IE8 以及 IE8 7 模式下一切正常，但是...我们的客户端使用 Internet Explorer 7 遇到了问题，应用程序会冻结并且会出现一个脚本超时框，我在解决方案中投入了太多工作，无法将其丢弃，因此我最终花了一个小时左右优化脚本并尽可能添加 setTimeout。
我的建议？
I recently ran into the same problem and decided to go with browser side processing, everything worked great in FF and IE8 and IE8 in 7 mode, but then... our client, using Internet Explorer 7 ran into problems, the application would freeze up and a script timeout box would appear, I had put too much work into the solution to throw it away so I ended up spending an hour or so optimizing the script and adding setTimeout wherever possible.
My suggestions?
我同意你的看法。尽可能向用户推送，但不要太多。如果您的应用程序速度变慢，甚至更糟，导致浏览器崩溃，您就会松懈。
我的建议是实际测试应用程序全天打开时的行为。检查是否存在内存泄漏。检查应用程序使用一段时间后是否每半秒创建一次 ajax 请求（JS 中的计时器有时可能很痛苦）。
除此之外，切勿使用 javascript 执行用户输入验证。始终在服务器上复制它。
编辑
使用jquery 实时绑定。重新绑定生成的内容时，它将为您节省大量时间，并使您的架构更加清晰。遗憾的是，当我使用 jQuery 进行开发时，它还不可用；我们使用了其他具有相同效果的工具。
过去，当使用 ajax 生成一个页面部件依赖于其他部件生成时，我也遇到过一个问题。首先生成第一部分，然后生成第二部分将使您的页面按预期变慢。提前计划好这一点。开发一个页面，以便它们在打开时已经包含所有内容。
另外（也涉及简单页面），保持一台服务器上引用文件的数量较少。将 javascript 和 css 库加入到服务器端的一个文件中。将图像保存在单独的主机上，更好的单独主机上（仅创建第三级域也可以）。尽管这仅在生产时才值得；这将使开发过程变得更加困难。
I agree with you. Push as much as possible to users, but not too much. If your app slows or even worse crashes their browser you loose.
My advice is to actually test how you application acts when turned on for all day. Check that there are no memory leaks. Check that there isn't a ajax request created every half of second after working with application for a while (timers in JS can be a pain sometime).
Apart from that never perform user input validation with javascript. Always duplicate it on server.
Edit
Use jquery live binding. It will save you a lot of time when rebinding generated content and will make your architecture more clear. Sadly when I was developing with jQuery it wasn't available yet; we used other tools with same effect.
In past I also had a problem when one page part generation using ajax depends on other part generation. Generating first part first and second part second will make your page slower as expected. Plan this in front. Develop a pages so that they already have all content when opened.
Also (regarding simple pages too), keep number of referenced files on one server low. Join javascript and css libraries into one file on server side. Keep images on separate host, better separate hosts (creating just a third level domain will do too). Though this is worth it only on production; it will make development process more difficult.
当然，这取决于数据，但大多数时候，如果您可以将其推送到客户端，那就这样做。让客户端进行更多的处理并使用更少的带宽。 （这又取决于数据，您可能会遇到必须发送更多数据才能在客户端执行的情况）。
Of course it depends on the data, but a majority of the time if you can push it client side, do. Make the client do more of the processing and use less bandwidth. (Again this depends on the data, you can get into cases that you have to send more data across to do it client side).
像安全检查这样的事情应该始终在服务器上完成。如果您的计算需要大量数据并产生较少数据，也请将其放在服务器上。
顺便说一句，您知道您可以在服务器端运行 Javascript、渲染模板并访问数据库吗？查看 CommonJS 生态系统。
Some stuff like security checks should always be done on the server. If you have a computation that takes a lot of data and produces less data, also put it on the server.
Incidentally, did you know you could run Javascript on the server side, rendering templates and hitting databases? Check out the CommonJS ecosystem.
还可能存在跨浏览器支持问题。如果您使用跨浏览器的客户端库（例如 JQuery）并且它可以处理您需要的所有处理，那么您可以让该库来处理它。在服务器端生成跨浏览器 HTML 可能会更困难（往往更加手动），具体取决于标记的复杂性。
There could also be cross-browser support issues. If you're using a cross-browser, client-side library (eg JQuery) and it can handle all the processing you need then you can let the library take care of it. Generating cross-browser HTML server-side can be harder (tends to be more manual), depending on the complexity of the markup.
这是可能的，但是初始页面加载量很大&&大量使用缓存。以gmail为例，
在服务器和客户端之间分配工作负载是明智的做法。
this is possible, but with the heavy intial page load && heavy use of caching. take gmail as an example
Its smart to split the workload between your server and client.
如果您认为将来您可能想要为您的应用程序创建一个 API（与 iPhone 或 Android 应用程序通信，让其他网站与您的网站集成），如果您使用应用程序的基本服务器实现。
If you think in the future you might want to create an API for your application (communicating with iPhone or android apps, letting other sites integrate with yours,) your would have to duplicate a bunch of code for all those devices if you go with a bare-bones server implementation of your application.