omi*_*xam -2 html javascript php asp.net-mvc server-side
我需要了解在客户端（JavaScript）或服务器端（PHP、C#、Java、Python、Cold Fusion 等）渲染 html 页面的优缺点。
安全性、性能、良好实践如何？
提前致谢！
尝试这个..
服务端 HTML 渲染：
最快的浏览器渲染
页面缓存可以作为一种快速而肮脏的性能提升
对于“标准”应用程序，许多 UI 功能都是预先构建的
有时被认为更稳定，因为组件通常需要进行编译时验证
依靠后端专业知识
有时开发速度更快*
* 当 UI 要求与框架很好地契合时。
客户端 HTML 渲染：
更低的带宽使用率
较慢的初始页面渲染。在现代桌面浏览器中甚至可能不明显。如果你需要支持IE6-7，或者很多手机浏览器（手机webkit也不错）你可能会遇到瓶颈。
构建 API 优先意味着客户端可以很容易地成为专有应用程序、瘦客户端、另一个 Web 服务等。
依靠 JS 专业知识
有时开发速度更快**
**当用户界面很大程度上是自定义的，有更有趣的交互时。此外，我发现在浏览器中使用解释代码进行编码比等待编译和服务器重新启动要快得多。
安全：
您想要保护的任何数据操作都需要在服务器上完成。在客户端处理的任何数据都绝对可以操作。例如，如果您有一个 javascript 函数来处理一些信息，然后将这些信息回发到系统中——即使您具有示范性的后端安全性，也很容易在回发之前操作结果
服务器端验证将所有传入数据视为不受信任，它是进入系统其余部分的网关。客户端验证有助于为最终用户提供流畅的体验，并尝试减少来自服务器的一些负载。两者都到位后，您就可以完成上面的整个选项清单。
但是，如果您必须牺牲一个，则应该选择客户端验证。客户端提供了更好的用户体验和略少的服务器负载，但它以牺牲服务器端验证解决的所有安全问题为代价。从另一个角度来看，服务器端验证可以防止可能导致您停业的问题类型，客户端验证可以改善体验。
客户端
是的 - 它可以防止具有良好意图的用户的错误值
是的 - 它可以帮助好心的用户更正他们的价值，而无需服务器往返的开销
否 - 当脚本加载失败时，它可以防止错误的值（如 jQuery）
否 - 它可以防止由于恶意编辑 Web 表单（开发人员工具）而导致的错误值
否 – 它可以防止直接提交给端点的错误值（例如：跨站点请求伪造）
否 - 它可以防止在帧中访问时出现错误值
否 – 它可以防止通过中间人攻击更改数据时出现错误值
服务器端
这与客户端方法相比如何？
是的 - 它可以防止具有良好意图的用户的错误值
否 - 它可以帮助好心的用户更正他们的价值，而无需服务器往返的开销
是的 - 它可以防止脚本加载失败时出现错误值（如 jQuery）
是 - 它可以防止由于恶意编辑 Web 表单而导致的错误值（开发人员工具）
是 - 它可以防止直接提交给端点的错误值（例如：跨站点请求伪造）
是 - 它可以防止在帧中访问时出现错误值
是 - 当数据通过中间人攻击改变时，它可以防止错误的值
参考：