酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
　　前后端完全分离其实一直是Web开发人员的梦想,也一直是我的梦想,遥想当年,无论是直接在代码里面输出HTML,还是在HTML里面嵌入各种代码,都不能让人感到满意.期间的痛苦和纠结,我想所有Web开发人员都深有感触.
由于最近几年一直在MS平台,从Web Form到MVC,MS平台虽然易用好学,但整合度太高而灵活性不足,一直没有找到很好的前后端分离的思路. (Java平台的兄弟如果已经有非常成熟的平台和思路,最好能简单留个言给个帖子地址或者技术名称,不胜感激).
ASP.NET的MVC模式的确是向前后端分离迈出了一大步,但我认为目前的模式还是不彻底,我看过园内的一些文章,大家都认为这是Controller层的问题,但我认为还是View层的问题,View层的输出还是需要经过Controller通道,也就是说Controller依然影响 &页面渲染&的最终效果, 使得目前的MVC也仅仅只能是Servlet, JSP, Web Form的升级模式,离真正的前后端分离还是有一定的距离.
不过,目前OWIN标准的出现和MS的自我革命,使我开始重新思考前后端分离的核心问题,结合之前Web开发遇到的问题和心得, 我希望能和大家一起交流下这方面的思路和体会.
前提条件和必要性
从目前来看,Web开发技术的日益发展和Web系统需求的日益的提高,使得前后台分离的条件日益成熟,而必要性也日益提高.我总结为3句话来概括就是:
前端无所不能,通道日益便利,需求日益明确.
HTML/CSS标准的发展使得前端表现日益丰富
　　在近年Web前端技术的竞赛中,HTML5/CSS3显然还是是领跑者,它们标准的不断发展也给前端实现带来了更多可能,介于这两种技术是任何模式的必选,这里就不加累述了.
JS框架的不断发展使得前端开发无限可能
　　通过不断的发展和无数高手的努力,&JS能实现任何功能&已经不是一句笑谈, 连& Atwood定律& 这种略带轻狂的言论也被越来越多人所接受.
如今,内有JQuery, Dojo这种简单易用的基础函数库,外有AngularJS和BackBone这种牛逼闪闪的框架实现. 在JS的肩膀之上,前端开发事实上已经具备无限可能.
RESTful Api和Json的发展使得前后端交互日益便利
当然,分离以后就存在交流的问题,如何快速,简洁,有效,统一的在前后台进行信息的交互,成为分离以后必须考虑的问题.
幸运的是, RESTful思想和Json数据标准的出现,使得这种交互日益便利,在前端,我们耳熟能详的JS技术和框架对RESTful和Json的支持可以说已经水到渠成. 至于后端,不管什么语言,什么平台都有非常成熟的方案.
前后端的不同发展趋势使得前后端分离需求日益明显
众所周知,Web开发自出现以来一直存在性能,表现和体验的先天不足,但时至今日,事实已经并非如此,一些看上去甚至比桌面程序更炫的应用和网站横空出世,客户也被吊足了胃口.Web开发桌面化已经是无法阻挡的潮流,而前端开发的需求应该会向更加注重界面表现,速度流畅,用户体验的方向发展,而且要求只会越来越高.
而在后端,稳定,性能,安全,存储,业务等核心问题依然是主流,所以前后端的需求必将日益分化,注重表现和注重内在的前后端开发人员必将需要适合自己的舞台.
所以我认为未来Web开发,前后端的完全分离应该是一个值得考虑的方向,我的想法比较简单明了(可能比较简单,希望大家多多斧正),看下图:
要实现这种分离,我认为有以下四大原则:
前端静态化
前端有且仅有静态内容,再明确些,只有HTML/CSS/JS. 其内容来自于完全静态的资源而不需要任何后台技术进行动态化组装.前端内容的运行环境和引擎完全基于浏览器本身.
后端数据化
后端可以用任何语言,技术和平台实现,但它们必须遵循一个原则:只提供数据,不提供任何和界面表现有关的内容.换言之,他们提供的数据可以用于任何其他客户端(如本地化程序,移动端程序).
平台无关化
前端3大技术本身就是平台无关的,而后台连接部分的本质是实现合适的RESTful接口和交互Json数据,就这2者而言,任何技术和平台都可以实现.
构架分离化
前端架构完全基于HTML/CSS的发展和JS框架的演变,与我们耳熟能详的后台语言(如C#, Java, NodeJs等)完全无关. 由于前台是纯静态内容,大型构架方面可以考虑向CDN方向发展.
后端构架几乎可以基于任何语言和平台的任何解决方案,大型构架方面, RESTful Api可以考虑负载均衡;而数据,业务实现等可以考虑数据库优化和分布式,这些领域园内大牛如云,就不再班门弄斧了.
但总而言之,前后端的分离也实现了前后端构架的分离.
分离模式的优势
前后端流量大幅减少
　　我们知道,前后端流量的大头是HTML/JS/IMG资源,而数据仅仅是小头,资源占到100K以上的页面不算大,但数据充其量10K左右,比如一个1万条记录的数据经过压缩也仅仅在100K左右,而一个稍大的JS库或图片就不止这些.
　　流量的减少在于&前端静态化&这个规则,在第一次获取以后静态资源会被浏览器缓存,即使浏览器继续轮询,服务端也会返回一个非常小Not Modified响应,流量几乎可以忽略不计.
举例说明,在一个页面为100K,数据为10K的页面中,100次请求的流量是100K+10X100 = 1.1M. 显而易见,其流量是大幅低于每次获取完整HTML的情况的.
表现性能的提高
也有人质疑这种模式的页面性能问题,其实情况没有那么悲观: 第一次获取的确会有些许损失,但我认为,损失微乎其微,一个HTML页面的加载,同时加载10多个几十K的JS, Image的情况非常常见,再多1-2个10K的Json也并非沉重负担.
但后续使用这个页面,性能优势就完全体现了,页面的绝大部分内容都是本地缓存直接加载,远程获取的仅仅是1-2个10K的内容,其加载时间百毫秒内,这和本地页面几无区别,其前端加载和响应速度得到非常大的提高是显而易见的.
前后端平台无关和技术无关
前端是纯HTML技术,前端人员只需要记事本就可以开发并非一句&戏言&,而后端能够实现RESTful的框架和平台比比皆是, 完全可以选择更适合团队,人员和公司的技术路线而不在纠结于平台和技术的选择.
安全性方面的集中优化
前端静态化以后,前端页面攻击几无可能,一些注入式攻击在分离模式下被很好的规避; 而后端安全问题集中化了,仅仅只处理一个RESEful接口的安全考虑,安全架设和集中优化变得更明确和便利.
开发的分离和构架的分离
　　也许很多团队还是1个开发人员全包前后端的模式,但我也提到了,前端的要求越来越高,前后端人员的需求分化日益明显,一旦系统上级别上档次,其分离的需求必将出现.
　　前后端人员的完全分离可以使得他们在各自领域进一步求深求专,成为更加专业的高手;另外,前后端的构架也可以分开考虑和架设,前端构架就能集中考虑性能和优化,而业务,安全和存储等问题就能集中到后端考虑.
常见问题解决探讨
这里我阅读了几位园内高手的文章:
夏天的森林 -关于大型网站技术演进的思考（十四）--
系统架构：
吕大豹（Double.Lv）的
可以说受益匪浅,而针对他们提出一些的问题,也尝试在自己的构想下进行寻求解决方案:
页面逻辑和呈现效果: 还是刚刚的一句话,JS已经无所不能,依托于目前的各种JS函数库和框架,在获取到合理的数据以后,几乎没有做不出来的逻辑和效果. 我本身偏向于前端实现,对这点有疑问的朋友我们可以深入交流. 至于有些园友提出的数据校验,页面白屏,路由控制,代码复用等等问题,前端技术已经完全可以解决.
服务器性能和优化: 由于前端内容是完全的静态内容,在初次获取以后的大部分时间内,浏览器使用的就是本地缓存,也就是说,服务器的压力主要来自于承载数据的RESTFul Api调用,压力的大幅降低不言而喻.加上对交互数据的合理设计,可以说对客户端-服务端的交互量控制已经接近极限.
安全性: 由于前端静态内容仅仅只能获取,而后端只能接受Json,应该说,屏蔽了大量可能发生的注入型问题,而一些其他问题,比如非法对象,数据加密,DDOS等问题,这些本身就是后端人员无法回避的责任,在任何模式下都必须考虑.
跨平台,跨技术: 正如刚刚所所说, 前端技术本身无平台限制,而后端几乎任何平台都能实现.
企业级构架考虑: 前端考虑搭建CDN,后端考虑负载均衡,数据库优化和分布式设计.关键问题是,前后端构架可以分开考虑,各自交给其专业人员去架设.
测试: 前端JS已经出现非常优秀的单元测试框架(AngularJS),而后端RESTFul测试技术早已驾轻就熟.
SEO: 的确是一个问题,但通过OWIN或者其他HTTP Module桥接技术,转接一部分HTTP路由到SEO功能并非难事.
开发技术:前端人员只需要学习HTML/CSS/JS,而后端人员只需要学习后端语言.几乎不需要穿插.
Ajax跨域:如果远程调用或者内部少量调用,可以考虑后端转接和JSONP,内部构架分离可以考虑CORS.
软件开发,项目管理,开发管理,团队管理. CMMI,PMP
& 相关主题：分享本人对 Web 前端开发的看法，比较偏门的视角 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
- a JavaScript code quality tool
分享本人对 Web 前端开发的看法，比较偏门的视角
· 173 天前 · 3886 次点击
最近郁闷着准备找新工作，充电之余写了点牢骚话
某些术语用得不太准确，请无视
因为个人涉足的领域有限，可能某些地方理解较肤浅，比较主观
但我不是来伤害某些人的感情的，欢迎评论及提 issue
第 1 条附言 &·& 173 天前
我认为技术应该要越来越易用，如果技术难用，创意就难实现，如此而已。
我不是跟大家争论语言问题，不是想引战。
第 2 条附言 &·& 173 天前
看了评论，我想到自己写的时候没提及到的是开发人员的“两极分化”，不过要涉及到心理的东西，还是不要扯的太远好了 不太懂
73 回复 &| &直到
00:20:43 +08:00
& &173 天前
flash 漏洞百出 各种本地 io
浏览器沙箱模型碰到它基本就成摆设了 我真不知道 adobe 一家之力是怎么让 flash 活过来的还活得这么好
另外你要是黑任何一门语言都有理由 比如：
php 的特性坑和标准库坑太多
py 版本分裂
java 语法冗长 标准库接口设计反人类
c#生态不好 社区太少遇到问题只能找微软
c++的模板可读性差编译效率低下
c 语言字符串处理弱 轮子少需要手写数据结构 posix api 还不兼容
等等等等。。。
& &173 天前
@ 我没打算黑语言。你说 Flash 漏洞百出，你也可以套到任何一个软件上面。因为 Adobe 有做工作，所以 Flash 能活
& &173 天前 via Android
确实理解得比较肤浅，而且很主观~
& &173 天前
@ 从安全中心收到 issue 的数量来看， flash 漏洞的确要多很多。况且 flash 是跟 jvm 一样的平台级的东西，如果 jvm 隔几天就报一个安全问题，你怎么看？
& &173 天前
@ 我理解你的意思就是说，漏洞百出的技术就渣，完毕。没有 HTML5 之前，大家要做网页应用是怎么做的？ Java 也有因漏洞问题被屏蔽过的历史，而且大苹果也有份
& &173 天前
支持楼主的想法。有不一样的意见挺好。
我也认为前端在工程化上走火入魔，而忽视从产品和用户的角度发现／解决问题。
& &173 天前
@ 谢谢。 这里还有一篇老外写的
& &173 天前
好吧。那就忽略你黑 js 的那些话。其实我觉得 js 是个尝试，现在有太多的基于继承的 OO 语言（也就是狭义上的 OO ）， js 是个异类，换个口味，不是很好嘛。虽然 js 有些东西的确很渣，但起码是一次尝试，值得鼓励。
前端 mvc 实际上就是把 b/s 写成 c/s 。模板的组装是肯定要有的，你不在前端组装就在后端组装，工作量是一样的。在前端组装就省了服务端的部分压力。而且这样一来服务端就只需要提供 json 形式的接口，假如以后要开发移动端，后端也不需要变任何东西。
& &173 天前
本来的 Web 是为了呈现内容，现在硬是做成 App 了。
& &173 天前
@ 我觉得只是为了呈现内容的话，发明电视就够了，没必要有计算机。计算机就是为了交互而生的。
@ 简直黑没黑到点子上。 node.js 的最大黑点就是单线程异步模型。如果把它托管给 apache 或者 nginx ，然后应用这边就相当于是同步的了，代码逻辑也能理顺。作者却拿 node 的包说事，好像 python 写个什么东西都不需要包似的。
& &173 天前
我赞同撸主的看法，现在的 JS 和几年前的 AS3 很像。
AS3 让一大波做动画的华丽变身成程序员，拿着超高的薪水，每天制造着垃圾代码。
现在的 NodeJS 出现让一大波做网页的华丽变身成后端工程师，甚至架构师，还是一样拿着超高的薪水，制造着垃圾产品。
我不针对 AS3 JS 或 NodeJS ，技术无罪。但是我鄙视那些趁火打劫，拉低整个程序员职业社会地位的乐色。
libuv 你吃透了么？ epoll iocp select 等 io 模型理解了么？
& &173 天前
不是每个公司都会专门去招一个 C++码猴去改 Webkit 核心与网页内容交互可以说我是第一个把新技术带给现在所在的公司的前端，在这之前他们是无法想象让自家的网页版应用与系统整合完成一些特殊的功能的入门成本低确实会带出来很多只会写 jQuery 的人，但是也不能因此觉得 Web 技术不能做 App 吧，一个人也可以搞定一个网站+客户端了，哪里不好呢？如果你是觉得前端写不好代码，那么写后端的大牛还是不要碰界面相关的东西了，审美那么差，写什么界面，难用的要死
& &173 天前
单页应用能减少页面跳转，这一点就让体验上升了一个层次。
至于弄丢了的历史记录，加个 route 记录管理就好了。
web 页面的基础是浏览器， App 的基础是 OS ， web 前端所做的这一切工作是为了使 web 体验更接近 App ，并超越 App(无需安装，兼容多平台)。
说了这么多，怎么实现呢？只有 HTML 、 CSS 、 JavaScript 可以实现上述需求。
“什么都用 JavaScript 去解决问题”，因为“制作 App 不再需要懂 Java 或者 Objective-C/Swift 了”。
“也就是说 JavaScript 要升级了”，因为需求膨胀了。
& &173 天前
@ 
English!
& &173 天前
@ 
发不了图-_-||
& &173 天前
这个语言一直这样，上限特别高，下限特别低，只不过现在用的人更多了，玩的花样也更多了。
最近又重温了一下老道的演讲
只能说讲的实在太好了
& &173 天前
那堆东西确实搞起来好麻烦啊，两者比较我宁愿去用 swift 写原生的
& &173 天前
感觉像是把英文那篇的观点复述了一遍，而且理解还比人家浅...
& &173 天前
@ 说得对， Web 做成 App 的需求是有的，对 App 模式的局限性进行互补。 Flash 早就是用 C/S 模式运作的，我明白 SPA 的意思。但是你说模版肯定要有我不太认同，那是后台开发引入的概念，前端／客户端开发者应该更熟悉的概念应该是 UI 组件，就像 App 开发时用的那些。所以我想吐槽 Angular
@ @ 本来需要分工的却凑在一块，对应领域相关知识不是说换工具那么简单，要是这样的话给你一把菜刀就能当厨师。一个新技术出来不是不好，往往就是形成了误导之后，各种误用
@ Routing 的概念对应用开发其实不是必须的，那是因为考虑浏览器的问题，前进后退历史这些。 Flex 框架也出现过类似的东西叫 deep linking
@ 明智的人当然分得清 Good or Bad 但不是所有人水平都一样，对于 JS 这种弱类型、自由度又异常高的语言，没有规范的前提下ˊ_&ˋ
& &173 天前
@ 谢谢你提供视频的视频链接 看来我不应该只说 most popular...
The World's Most Misunderstood Programming Language 这个头衔更贴切
& &173 天前
“所以，如果你问我 Angular2.0 的前途会怎样，我也不想再过多解释了，用后台开发的思想去控制前端开发， I think ，大多数传统的前端开发人员都水土不服，更别提切图工了^_^”
@ ，撸主为什么认为 angular2 是“用后台的开发思想去控制前端开发”？
& &173 天前
angular bring js to html,相比 react 来说,对切图工更友善甚至是 angular 的一大优点...只关心撸主是否真正使用过 angular
& &173 天前
@ 写的有点偏差了抱歉，可能要把 2 个版本统称 Angular ，虽然 2.0 完全是另一回事，但有些核心的东西还是继承 1.x 的。因为对于只做过前端范畴的我来说， Angular 大部分概念都是新的， Web 系统里不是前端就是后端，或者应该说它集合了很多思想。本来这东西只有一定适用范围，不是万金油，过度宣传会造成误导
我觉得前端的重心是界面表现。 Angular 是一整套很优雅的方案，当要关注一整个“优雅”就会显不出重点，你可以见到大多 Angular 教程是给你默认用 Boostrap 和 Material ，它不会再多的教你如何做好界面。而最终用户看得见摸得着的却是这一层，管你里面多优雅
此外写之前我做点了功课
& &173 天前
诶 搞错了- -# @
& &173 天前
既然这么说，我是不是要把整个 V8 都给吃透了才能出师呢，新技术的出现本身就是为了让更多的人去方便使用，所以门槛会越来越低，这个趋势无法阻挡。
& &173 天前 via Android
使用组件的方法是获取组件，然后设置值。使用模板的方法是设置数据源然后自动绑定。后一种方式虽然反直觉，但 angular 真的比 jquery 少写很多代码。
再有就是熟练度的问题了，由于思维模式完全不一样，重新适应需要一段时间。我就是因为懒才不愿意从 jq 迁移到 angular 。
& &173 天前 via Android
@ 一个语言领域广是好事，门槛低是好事。就像你不能既羡慕 java 社区的繁荣也吐槽 java 程序员水平低。多少好的框架好的思想正是从这么多的垃圾解决方案里整理和抽象出来的。
& &173 天前 via Android
@ 你是没有在各种语言上编写 gui 程序的经历。 html 再怎么说也是一套规范一种标准，比直接使用各种 gui 库要重新适应 api 还不方便迁移要好得多。
我不知道 ios 上怎么样，安卓的 xml 和 style 难用的要死，让我选肯定还是 html 。
& &173 天前
大部分人没写过 AS3 ，没用过 Flex 吧（像现在使用的 WEB 开发一样的频度和深度）？
撸主的文章写的有点乱，主题是担心 JS 沦为 AS 一样的下场？
JS 前端和后端混合这个事（前端可以直接引用 node_module ）是挺容易混淆开发人员的开发视野的（低质量程序员），另外 6L 说的工程化也是一个值得深思的问题。
但是 JS 世界应该不会有和 AS 一样的命运，根源在于大家并不信赖 Flash 依赖的自己实现的浏览器内的虚拟机，当然媒体的妖魔化也是原因之一。但是对于 JS 直接依赖于浏览器这种方式更能接受一些。
有人说 Flash 一堆 BUG ，这个问题没有考量到： AS 是 Adobe 一个团队在开发和维护，自己实现了几乎全部的核心的功能，它不是开源代码，无法做到把责任分散给开源社区来分担。而 JS 的状态则是 vanilla js 的世界并不是核心，核心是目前充斥开源社区的框架和插件和工具，如果把这些开源社区的 ISSUE 整合起来， BUG 量比 AS 自家产生的 BUG 是只少不多的。
所以 AS 的问题只是在于它不开源。
Angular 的 directive ，在写法上和 SilverLight 以及 Mxml 的想法是如出一辙的。
& &173 天前 via Android
互联网是开放的，由用户决定，而不是技术。
& &173 天前 via Android
js 不会像 as 那样就是因为 js 是 w3c 默认的语言， w3c 和 mozilla 基金会拼死也得维护它。
flash 的 bug 主要是因为封闭性。所以等 web assembly 完全实现后，浏览器内的 bug 肯定会直线上升。 web 开发者写个 c 语言，弄出个 buffer overflow 简直太容易了。
& &173 天前
@ 写界面肯定是 HTML ， css 方便。但 JS 框架工具那个乱啊，让人望而却步。当然我是那种只想用工具来方便完成事情，不想被工具玩的懒人。
& &173 天前
这不是 civet 大神吗...
wonderfl 看过您的很多作品...
还曾经尝试学习过 你制作的播放 midi 的 flash 可惜没有学成...
flash 挂掉的主要原因之前看了某个文章
是因为早起 MacOS 乔布斯求 adobe 把行业标准视频处理软件 adobe pr 开发个 MacOS 版本吧
当时乔布斯被拒绝了
后来 iPhone 1 的时候 adobe 说 把 flash 加入 iOS 吧 ...乔布斯:呵呵
-----
PS:本人对前端接触不多, 也不愿太多
HTML5 渲染效率太低...
不过前端做出的很多东西也不是拼效率
很多轮子 拿来可用 快速成型 才是特点...
不过因为兼容问题 有历史遗留问题
没办法和做 AS3 的时候一样愉快的处理
所以要是我选择的话 应该会是走 iOS 学习 Swift , 附带点 轻量玩后端的知识
& &173 天前 via Android
@ 是的。所以说 jquery 应该被纳入 w3c 标准，然后就只剩一大堆框架在那儿撕逼了。不想用框架的人直接用原生 api 也能解决问题。
& &173 天前
@ 我想再补充一下说法。
Flash 没有说过不开源，而是业界一直不接受这么个东西。毕竟 Adobe 不像 Mozilla 这样的组织， Adobe 是个商业公司。曾经 Adobe 将虚拟机捐给 Mozilla (
JS 是没有等 ES4(也等不到)而绕到 5 的。
而 Adobe 的商业决策也是失利的，他们不懂怎么持久地经营技术。结果让 Flash 身先士卒，让 HTML5 踏着它的尸体前进。但很可惜，很多做 Flash 开发后来都继续去做游戏，做 Web 应用方面并不多。所以我也只好自认是偏门了，但是现在评论面对的是各种功力深厚的大大
& &173 天前
“用后台的开发思想去控制前端开发”
编程领域分什么后台思想前端思想么？解决的问题规模有区别而已
& &173 天前 via Android
@ so ？我觉得那老外很搞笑~fb 开发 react 是为了解决通知中心的问题？这不过是 fb 在发布会上举个例子~然后我也很奇怪你告诉我有这篇文章是什么目的？证明有个老外跟你一样理解不深又主观？
& &173 天前 via Android
@ 你可以试一下只用 jquery 开发大规模应用，你就知道框架有什么用处了。
& &173 天前
于是其实就是不爽经常用的东西被判死刑？
虽然我最常用 JavaScript 但是如果有更好的语言我还是毫不犹豫抛弃它
& &173 天前
html5+css3+js+jquery+vue.js 基本能覆盖 80%以上的需求了
& &173 天前 via Android
不喜欢就不学咯，你是自由的。
& &173 天前
avm 开源了，但是没有任何引导怎么做 contribution ：
tarmarin 只是部分会被 avm 实现：“...The code will continue to be used by Adobe as part of the ActionScript(TM) Virtual Machine within Adobe(R) Flash(R) Player.”因为它是 ECMAScript4 的核心，并不只是服务于 avm 。
& &173 天前
全文都带着戾气啊，看着像一个 Flash 开发者不甘心看到 JavaScript 飞速发展，而自己的 Flash 却没落了
& &173 天前 via Android
@ 我从来都是只用 jq 的。另外轮到我写前端的机会不是很多，没办法尝试。
& &173 天前
@ 随你怎么理解。 38 楼的回复只说明你断章取义
& &173 天前
@ 你这样说我真只能笑了。每个人的遭遇不一样
& &173 天前 via iPhone
@ 说 react 是为 iOS 程序员开发的这点也很猎奇
& &173 天前 via Android
@ 其实你是想讨论“数据绑定”这个东西吧（或者叫 mvvm ）
& &173 天前
楼主从一个比较长的软件发展阶段来抒发关于 web 前端开发技术更迭循环的看法，对于我一直在做 C/C++,Java 及相关 C/S 结构所谓的后端开发打拼的人，总是看不清前端到底在折腾神码东西有了更进一步的认识，果然还是有前端的人终于从历史到如今到未来发表了自己的看法，不是一味的好评，值得学习。时代更迭，展示硬件平台的变更加速着软件展示层面的技术更迭，如见的 WebApp 不还是干着早先 Flash ， AIR ， MFC CDHtmlDialog 所干的事情。最后“ Angular 是吸引 Java 程序员而来”的说法，我只能呵呵了，闲等它被淹没在历史的技术洪流中，而 Java 程序员还是可以作出更好更精彩的东西。
& &172 天前 via Android
@ 其实说白了觉得用 jquery 就可以了的就跟用 servlet 就能开发 j2ee 差不多一个意思
& &172 天前 via Android
@ 彼此彼此吧~对于这种不怎么理解还非得出来发表自己的看法的，就像会写个 jsx 就觉得自己精通 react 了差不多，我也没什么好说的。你搬那老外的文章出来无非就是，“你看，人家老外也是这么说的吧”的意思嘛~我懂，你开心就好
& &172 天前
& &172 天前
@ 不一样。模板和 orm 是必要的。前端的数据绑定是不必要的，因为完全可以转移到后端来做，工作量是一样的，就是绑定的时机不同，以及后端多花一点开销。
& &171 天前 via Android
@ 负责任得告诉你，模板和 orm 并不是必要的，有很多方式可以做前后端彻底分离。分离带来的好处不仅仅是让后端少一点花销，流量开销，用户体验提升，不依赖后端之后前端架构的提升带来的开发效率提升都是很重要的点。你以为业界都在吵吵说前后端分离是在玩？所以还是那句话，用 servlet 就能做 http 服务器，何必用 spring ？
& &171 天前 via Android
@ 你调用 json 接口也算是依赖后端，后端改接口你前端也得改。对于你们前端来说，只是换个格式写模板而已。
另外 spring 的 ioc 还真不是必须的，大多数框架根本不带 ioc ，大多数公司也根本用不到 ioc 。都是跟风。
& &171 天前 via Android
@ 打个比方，我可以自己写个模板引擎，照样能把 angular 在后端渲染了，而你们根本不需要改动任何开发流程，你信不信？
& &171 天前 via Android
@ 什么时候 angular 就是和模板引擎了？你当然可以实现个模板把数据一次性显示出来，然后呢？数据绑定，组建服务？你以为还是在 10 年前前端还是没什么操作的年代？
& &171 天前 via Android
@ 数据绑定屏蔽掉，回调的逻辑是正常的，这很简单。
更何况，你用 angular 就是最开始显示数据的时候痛快，回调呢？回调代码量不是和 jq 一样吗？
& &171 天前 via Android
@ [手动 doge]，回调代码量一样。。。先不说 promise ，你做一个企业站你写的 java 代码还没一个 spring 的包多呢，你干嘛还用 spring ？
& &163 天前
我这里暂且不吐槽前后端真正“分离”的说法。
你们前端真是只会用轮子不会造轮子。连 angular 的基本原理都不清楚。呵呵了。
看来前端视野太局限了，还需要学习一个。[手动 doge]
& &163 天前
@ 你睁大眼睛看看是不是一样？
```
// angular
$http.get(url).success(function(data) {
$scope.name = data.
$scope.age = data.
$scope.click = function() {...};
});
```
```
// jq
$.get(url).done(function(data) {
$('xxx-name').text(data.name);
$('xxx-age').text(data.age);
$('xxx-button').click(function() { ... });
});
```
还 promise ， jq 早就支持 promise 了你造吗？
& &163 天前
@ 哟，还跟我讨论 angular 的原理呢，你要是知道 angular 原理还能说出来跟 jquery 一样你的脸皮真是厚道原子弹都打不破。你举的例子叫一样？上面的代码能在 view 层复用，下面的代码改个 id 你还能复用么？ angular 是 data=&UI 的驱动模型你知道么？看起来像就是一样？“看来前端视野太局限了，还需要学习一个”这句话用在你身上那是再好不过了。不懂别在那装懂，看着都觉得羞耻
& &163 天前
@ 还有，举例子举得详细一点，获取数据每个框架都差不多。当然深度的例子估计你也举不出来，毕竟眼界就那样。估计在你看来 react 跟 angular 也就是一个东西，估计你也不知道如何模块化。另外过了这么多天才回复我，是先去学习了 angular 再回来给我举例子吧？这么久还只能举出这样的例子，哎~劝你别玩前端了。
& &163 天前 via Android
@ 你前端除了给后端做展示， curd ，还能干嘛？
我告诉你， mvvm 这种东西在 gui 编程里也有（比如 wpf ），但是不吃香的原因就是前端做的事情都是 curd ，太简单了。 gui 应用（特别是那些功能性的）不存在一个单一的数据源，你想 mvvm 也没办法。也就是你们前端 curd 用 mvvm 方便。
我以前是做 gui 应用的，维护的应用少说 5 个窗体，多了要十几个，我照样不用任何绑定，就是获取控件然后访问，我完全控制得了。
说你眼界低还不相信，你知道网页加载完了之后 angular 首先要干嘛吗？ angular 不需要遍历 dom 树然后解析双花括号？解析双花括号不是后端模板引擎的做法？你 angular 的语法不是跟 jinja 学的？就知道什么业务逻辑驱动模型，让你写个 parser 估计都跟抽筋似的。你根本没写过这些东西，所以跟你说移植到后端也是对牛弹琴。
& &163 天前 via Android
@ angular 的代码还复用呢，笑死我了，把 ng-app 和 ng-controller 一改，连$scope 都取不到了，还复用呢。
另外我啥时候说过 jq 和 angular 原理一样了？我只是说，数据先用后端模板渲染好，回调用 jq 来做，完全可以实现一样的功能。（实际上这一直是传统 web 的做法）至于你们前端怎么舒服，我是搞后端的管你们干嘛。
从执行效率来看， angular 的确解放了后端渲染模板的压力。浏览器开缓存的话也可以省一部分流量。
从开发效率来看，处理数组在 angular 里就是一行赋值，而在 jq 里面，需要写个循环、创建节点、赋值、插入节点。
但是 so what ？难道大部分网站不迁移至 angular 的原因是这些优点比不过带来的重构成本和学习成本吗？
& &163 天前 via Android
@ 噗，还跟 jinja 学的，后端模板引擎一大堆，目的是为了渲染，前端模板引擎也是渲染，看上去当然差不多，但是意义一样么？你用后端引擎能实现前后端分离么？知道为什么要分离么？你公司如果有 app 和网页客户端，用的接口都是类似的，你不分离后端就要多写一套，后端服务化听说过没？
再次用前端渲染可以做切换效果你用后端模板来个试试？前端渲染可以做更多体验好的交互体验你用后端模板试试？写个 parser 你就高潮了？前端 orm 听说过没？
还移植到后端，大家都在往前走你偏要往后走，还大喊着你们都走错了我也是醉了，你这么牛逼怎么没见你出个文明全球的开发模式？
早跟你说你跟不上时代了还不信~呵呵
& &163 天前 via Android
@ 问题是我分离也得写两套。一套是静态页面，一套是 json 。这两个东西显然得分配两个路由。
然后分离之后 req handler 的逻辑是读页面 /数据、刷给 out 。分离之前是读页面、读数据、渲染、刷给 out 。
& &163 天前 via Android
@ angular 干的事情就是之前后端模板引擎干的事情，只不过 angular 是遍历 dom 解析的，后端引擎是整块 split 来解析的，我说它是模板引擎，怎么就不对了？
还数据绑定，有必要搞这么高大上的名词嘛？
是， view 移到前端是趋势，以后也会有人移植各种语法的引擎到前端来用。“一切东西都会用前端的技术重做一遍”，但是你说是引擎也好，框架也好，他们的发源地是后端。
& &163 天前 via Android
@ 分离之后后端就解放了，只要接口设计得好，比如 restful 化之后就不用管调用数据是 web 还是 app ，而且由于接口和业务是解耦的，所以业务变更你的接口基本不需要动，这就是分层的意义。
如果我理解你的 json 是借口，那么接口就是服务层，定义完之后就不会随着业务变化而变化的。所以等你们公司的网站变成一个两个， aop 出了三个四个，服务只要一个就够了。
所有东西你都可以看成是读数据，渲染数据，输出。至于能把这些结合成什么样那就是你的本事了
& &163 天前 via Android
@ angular 可不只是模板引擎，他还是一个组建化框架，你用 jquery 出一个好的组建化方案看？除了组件化还有模块化，你给我来个？需要我跟你强调一下组件化和模块化的意义么？
数据绑定有什么不对么，你更新数据 ui 就变化这么叫有错么？是不是你又要跟我扯“实际上不就是模板渲染么”？
那 react 的虚拟 dom 在你眼里是不是也是模板渲染？知道为什么 react 渲染效率为什么比 angular 好么？
你难道不知道这些框架出现的目的是为了更好得做更好的产品么？
“服务器不就是套接字接收网络请求分析内容然后返回数据么”我是不是应该摔给你做后台的这么句话？
& &163 天前 via Android
组件？在正常的开发者眼里，所有程序集都是组件。'angular 是组件，但是 apache 也是组件，这是个非常正确但是没有任何卵用的词。
前端就不要跟我谈什么模块化了。 html 到现在都不支持 include ， es 到 6 才支持 import 。后端开发者一开始就接触架构和模块化，无论是包含还是导入。前端之前非常缺少模块化所以现在格外推崇这个词，但是你叫任何一名前端之外的开发者，他肯定会觉得程序不都是模块化的吗？这有什么。
所以我就特别讨厌吹捧名词的人，明明是个模板引擎，非得说成“组件化模块化的解决方案”。这种事情我觉得只有不懂代码的媒体才能干的出来。那我把接口说成“软件即服务”，你听着不一样别扭吗？
& &163 天前 via Android
@ 哎哟卧槽~100 多 k 的 angular 被说成模板引擎，笑得我胃疼。我也懒得跟你争，前端组件化都不知道，我再说下去也没意义。你继续用你的服务端模板引擎，我用我的 react
& &157 天前
JS 为啥现在这么流行，我觉得还有一个原因就是它能快速的将技术转化成利润， 想想一个公司仅用 javascript 一种语言就快速上线一个网站去赚钱，这个吸引力是很大的。
楼上很多人喷现在很多所谓全栈 JS developer 都是半吊子，但从不懂技术的高层来看他们就是效率很高，所以他们能拿高薪并不奇怪
& · & 1087 人在线 & 最高记录 1893 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.7.3 · 68ms · UTC 09:43 · PVG 17:43 · LAX 02:43 · JFK 05:43? Do have faith in what you're doing.