客户端逻辑或服务器端逻辑？
我已经完成了一些基于networking的项目，我遇到的大部分困难（问题，困惑）都可以通过帮助来解决。 但是我仍然有一个重要的问题，即使在询问一些有经验的开发人员之后： 当function可以用服务器端代码和客户端脚本（JavaScript）来实现时，哪一个应该是首选？
一个简单的例子：
为了呈现一个dynamic的html页面，我可以在服务器端代码（PHP，python）中对页面进行格式化，并使用Ajax来获取格式化的页面并直接渲染（服务器端更多逻辑，客户端更less）。
我也可以使用Ajax来获取数据（不是格式化的，JSON），并使用客户端脚本来格式化页面，并进行更多的处理（服务器从数据库或其他来源获取数据，并将其返回给客户端与JSON或XML。更多的逻辑在客户端和less在服务器上）。
那么我怎样才能决定哪一个更好？ 哪一个提供更好的性能？ 为什么？ 哪一个更方便用户？
随着浏览器的JS引擎的发展，JS可以在更短的时间内解释，所以我更喜欢客户端脚本？
另一方面，随着硬件的不断发展，服务器性能不断提高，服务器端逻辑成本也会下降，所以我更喜欢服务器端脚本？
编辑：
有了答案，我想简要总结一下。
客户端逻辑的优点：
- 更好的用户体验（更快）。
- 更less的networking带宽（更低的成本）。
- 增加可扩展性（降低服务器负载）。
服务器端逻辑的优点：
- 安全问题。
- 更好的可用性和可访问性（移动设备和旧浏览器）。
- 更好的SEO。
- 易于扩展（可以添加更多的服务器，但不能使浏览器更快）。
我们似乎需要在面对特定情况时平衡这两种方法。 但是，如何？ 最佳做法是什么？
除了以下情况外，我将使用客户端逻辑：
- 安全关键。
- 特殊组（禁用JavaScript，移动设备等）。
在很多情况下，恐怕最好的答案是两者 。
正如米高博尔所言，永远不要相信客户。 不过，我觉得如果你信任客户，这几乎总是一个问题。 如果你的申请值得写作，那么值得妥善保护。 如果任何人都可以通过编写自己的客户端并传递数据来打破它，那么这是一件坏事。 出于这个原因，你需要在服务器上进行validation。
不幸的是，如果您validation服务器上的所有内容，则通常会给用户带来糟糕的用户体验。 他们可能只填写一张表格，发现他们input的一些内容不正确。 这可能适用于“互联网1.0”，但今天的互联网上人们的期望更高。
这可能会使您编写相当多的冗余代码，并将其保留在两个或更多位置（某些定义（如最大长度）也需要在数据层中进行维护）。 对于相当大的应用程序，我倾向于使用代码生成来解决这个问题。 我个人使用UMLbuild模工具（Sparx System的Enterprise Architect）来模拟系统的“input规则”，然后利用部分类（我通常在.NET中工作）来生成validation逻辑。 您可以通过以XML等格式编写规则并从客户端和服务器层上的该XML文件（input长度，input掩码等）获取大量检查来实现类似的function。
可能不是你想听到的，但是如果你想正确地做，你需要在这两个层次上执行规则。
我倾向于更喜欢服务器端的逻辑。 我的理由相当简单：
- 我不信任客户; 这可能或不是真正的问题，但它是习惯性的
- 服务器端减less了每个事务的数量（尽pipe它增加了事务的数量）
- 服务器端意味着我可以相当确定发生什么逻辑（我不必担心客户端浏览器可以使用Javascript引擎）
可能还有更多更好的理由，但现在这些是我头脑中最重要的。 如果我想到更多的话，我会添加它们，或者在我做之前将它们提出来。
使用客户端逻辑（使用Ajax / JSON）编辑， valya评论允许（更容易）创build一个API。 这很可能是真的，但我只能一半同意（这就是为什么我还没有投票答复）。
我的服务器端逻辑的概念是检索数据，并组织它; 如果我有这个权利的逻辑是“控制器”（MVC中的C）。 然后传递给“观点”。 我倾向于使用控制器来获取数据，然后“视图”处理将其呈现给用户/客户端。 所以我没有看到客户端/服务器的区别与创buildAPI的论点必然相关，基本上就是：马匹用于课程。 🙂
…作为一个业余爱好者，我承认我可能会略微扭曲MVC的用法，所以我愿意在这一点上进行纠正。 但是我仍然把这个陈述与逻辑分开。 就API而言，这种分离是非常重要的一点。
我通常实施尽可能合理的客户端。 唯一例外，使我去服务器端将解决以下问题：
信任问题
任何人都可以debuggingJavaScript和阅读密码，等等。
性能问题
JavaScript引擎正在快速发展，所以这个问题已经不再那么严重了，但是我们仍然处于一个以IE为主的世界，所以当你处理大量的数据时，事情会变得缓慢。
语言问题
JavaScript是弱types的语言，它使你的代码有很多假设。 这可能会导致您采用令人毛骨悚然的解决方法，以便在某些浏览器上按照应有的方式工作。 我避免了像瘟疫这样的事情。
从你的问题，这听起来像你只是试图加载到表单的值。 除了上面的问题，你有3个select：
纯粹的客户端
缺点是你的用户的加载时间会增加一倍（一个空白表单负载，另一个数据负载）。 但是，表单的后续更新不需要刷新页面。 用户会喜欢这个，如果有大量的数据从服务器加载到相同的表单中。
纯服务器端
好处是你的页面会加载数据。 但是，数据的后续更新将需要刷新页面的所有/重要部分。
服务器 – 客户端混合
您将拥有两全其美的优点，但是您需要创build两个数据提取点，导致代码稍微膨胀。
每个选项都有权衡，所以你必须权衡他们，并决定哪一个给你最大的好处。
我没有听说过的一个考虑是networking带宽。 举一个具体的例子，我参与的一个应用程序都是在服务器端完成的，并且导致200Mb的网页被发送到客户端（如果没有大量重新devise应用程序的话，这是不可能的。 导致2-5分钟的页面加载时间。
当我们通过从服务器发送JSON编码的数据并让本地JS生成页面来重新实现这个function时，主要的好处是发送的数据缩小到了20Mb，结果是：
-
HTTP响应大小：200Mb + => 20Mb +（ 相应的带宽节省 ！）
-
加载页面的时间：2-5分钟=> 20秒（其中10-15分钟被数据库查询占用，这个数据库查询已经被优化到更远的地方）。
-
IE进程大小：200MB + => 80MB +
请注意，最后2点主要是由于服务器端必须使用糟糕的table-tables-table树实现，而客户端允许我们重新devise视图层以使用更轻量级的页面。 但我的主要观点是networking带宽节省。
我构build了一个REST风格的Web应用程序，在没有JavaScript的情况下， 所有的 CRUDfunction都可用，换句话说，所有的AJAX效果都是严格的渐进式增强 。
我相信有足够的奉献精神，大多数Web应用程序可以这样devise，因此侵蚀了许多服务器逻辑与客户端逻辑“差异”，如安全性，可扩展性，在您的问题中提出，因为在这两种情况下，请求都被路由到相同的控制器，其业务逻辑直到最后一英里都一样，其中JSON / XML而不是整个页面的HTML被返回给这些XHR。
只有less数情况下，AJAX应用程序比静态应用程序更加先进，GMail是我想到的最好的例子，那么需要创build两个版本并将它们完全分开（Kudos to Google！）。
我想就这个问题给我两分钱。
我通常赞成服务器端的方法，这是为什么。
- 更多SEO友好。 Google无法执行Javascript，因此search引擎将无法看到所有内容
- 性能更可控。 由于您几乎完全依赖于用户浏览器和机器来渲染事物，因此用户体验总是随SOA变化的。 即使你的服务器运行的很好，一台慢速的用户也会觉得你的网站是罪魁祸首。
- 可以说，服务器端的方法更容易维护和可读。
我用这两种方法写了几个系统，以我的经验，服务器端就是这样。 但是，这并不是说我不使用AJAX。 我所build立的所有现代系统都包含了这两个组件。
希望这可以帮助。
在这个阶段，客户端技术是领先的，随着Backbone，Knockout，Spine等许多客户端库的出现，并增加了诸如JSrender，胡子等客户端模板，客户端开发变得非常容易。 所以，如果我的要求是去互动的应用程序，我一定会去客户端。 如果你有更多的静态HTML内容，那么是去服务器端。 我做了两个实验，我必须说服务器端比客户端更容易实现。 就表演而言。 阅读这个，你会明白服务器端的性能分数。 http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html
我知道这个post很老，但我想评论。
根据我的经验，最好的方法是使用客户端和服务器端的组合。 是的，Angular JS和类似的框架现在非常stream行，它们使开发轻量级Web应用程序变得更加容易，性能得到了提高，并且可以在大多数Web服务器上运行。 但是，企业应用程序的主要需求是显示报表数据，可以在一个页面上显示500多条logging。 使用返回大量数据列表的页面，用户通常需要使这个庞大列表易于过滤，search和执行其他交互function的function。 由于IE 11及更早版本的IE浏览器在大多数公司都是“首选浏览器”，所以您必须注意，这些浏览器仍然存在使用现代JavaScript，HTML5和CSS3的兼容性问题。 通常，要求是在所有浏览器上使网站或应用程序兼容。 这需要添加shiv或使用原型，这些原型与创build客户端应用程序所包含的代码一起添加到浏览器上的页面加载中。
所有这些都会降低性能，并可能导致可怕的IE错误“此页上的脚本正在导致Internet Explorer运行缓慢”，迫使用户select是否要继续运行脚本或不创build不良的用户体验。
根据他们在现有应用程序中的偏好，确定应用程序的复杂性以及用户现在想要的和将来可能需要的内容。 如果这是一个简单的网站或应用程序与中小型数据，使用JavaScript框架。 但是，如果他们想要包含可访问性， search引擎优化; 或者需要显示大量数据，使用服务器端代码来节省数据和客户端代码。 在这两种情况下，请使用Fiddler或Chrome Developer工具等工具来检查页面加载和响应时间，并使用最佳做法来优化代码。
使用ASP.NET Core开发Checkout MVC应用程序。
我认为第二个变种更好。 例如，如果你后来实现类似'皮肤'的东西，你会感谢你自己格式化HTML服务器:)
它也保持视图和控制器之间的差异。 Ajax数据通常由控制器生成，所以让它只返回数据，而不是html。
如果您稍后要创build一个API，则需要在代码中进行一些更改
另外，我认为，“裸”数据比HTML更容易擦除。 例如，如果你添加一些风格的链接，你需要重新格式化所有的HTML ..或添加一行到你的js。 它不像html（以字节为单位）那么大。
但是，如果需要使用许多繁重的脚本来格式化数据，那么不要求用户的浏览器对其进行格式化。
只要你不需要发送大量的数据给客户端来完成这个工作，客户端就会给你一个更加可扩展的系统，因为你正在为客户端分发负载，而不是把你的服务器做任何事。
另一方面，如果您需要处理大量数据以生成less量html以发送给客户端，或者如果可以优化使用服务器的工作来同时支持多个客户端（例如，处理数据一次并将所得到的html发送给所有的客户端），那么可以更有效地利用资源来完成其他服务器上的工作。
如果你在Ajax中做：
您必须为残疾人士考虑可访问性问题（在Google中search有关networking的辅助function），而且还需要考虑旧版浏览器，没有JavaScript的用户，漫游器（如google bot）等。
如果你从来没有用过很多的JavaScript，那么你就不得不调侃“渐进式增强”。 简而言之，您必须让您的应用程序适用于旧版浏览器和那些没有JavaScript的应用程序（例如某些移动设备），或者如果它被禁用。
但是，如果时间和金钱不是问题，我会逐渐提高。
但也要考虑“后退button”。 我讨厌它，当我浏览一个100％的AJAX网站，使你的后退button无用。
祝你好运！
