动态数据放浏览器端处理还是服务器

首先当然是平安效果,不过平安方面最大的一点其实是观念的效果,没有平安方面的观念,在这种效果下讨论我觉得应该收不到什么效果的,所以团体觉得平安方面不需求展开说。

剩下就是跟平安有关的方面,也就是说,某一个运算,它从平安的角度放效劳器或客户端都没有效果,那放哪里好?

我觉得这实践上主要是作风的效果。

在静态HTML盛行以前,这基本不存在效果:少数代码都只是复杂的提交前的验证,阅读器中运转的JavaScript代码的输入都是从表单里来的,你没无时机把它放效劳器端。但是这里又可以分一种状况:验证的时分你算得一个和,也许在效劳器端你还需求用,这怎样办呢?由于这个场景下我们的JavaScript只是复杂的做一个校验来增强用户体验,JavaScript是很零散的,普通倾向于增添其复杂性。所以这个时分普通依然采取客户端验证后效劳器端再从输入去计算的战略。这种做法实践上也附带了一个额外的益处就是关于不支持JavaScript的用户代理,一切任务如常,独一的区别就是关于不支持JavaScript的用户代理,在输入不合法时多了一个(或许能够由于设计的不合理,多了数个)刷新的举措。

在静态HTML时代,这个效果实践上取决于前端的架构。

有时分是,效劳器采用REST作风发布信息,web前端需求再把这些信息组装出来,这时分没有选择,你只能在前端把它再计算出来,接口就能设计的更一致,更复杂,有利于HTTP代理以及散布式分发网络高效任务,并且增加传输的数据量,能提高web运用的功用。除了REST接口促使你这样做,前端假设采用MVVM也使得你需求这么做:由于你别无选择,运用中有一些相互关联的局部就是需求带一些计算。

静态HTML还盛行一种状况就是,从网络上传输入来的就是HTML片段,并且这些片段都是完全组装好的,前端所能做的就是将它们拔出到页面中。那这种状况显然也无法选择,需求的计算在效劳器那边都计算终了了。

抱歉似乎只是做了一些分类,不过我觉得这个效果确实是需求分类讨论。

等候其他知友能带来一些精彩的分享。

提供最优质的资源集合

立即查看 了解详情