如何看2015年1月Peter-Paul Koch对Angular的看法?

The problem with Angular In the last six months or so I talked to several prospective clients that had a problem finding front-end consultants in order to help ...
关注者
396
被浏览
27435

6 个回答

感谢邀请。早上看到阮一峰老师转发了这篇文章,中午手痒翻译了一份:

[翻译]Angular的问题 · Issue #15 · xufei/blog · GitHub

认真地说,这篇文章的很多观点我还是很赞同的,而且令人印象深刻,比如说:

Angular更多地是面向企业的IT部门,而不是前端人员。
非前端人员做给非前端人员用的前端框架。
Angular更多的用户是有Java背景的人员。
Angular是面向大型企业的IT后端和经理们的。
对很多前端人员而言,最大的问题是,Angular强迫自己用一种指定的方式去干活。
当遵守AngularJS的约定时,生产力会更高。
对于一个前端人员,习惯于用特定方式来做事,迁移到Angular的方式可能比较痛苦。

整个文章比较深刻,该说的东西都说到了,但我还是有一些话要说。

首先,他把Angular想要面对的领域搞错了。我想要先问几个问题:

1. 有没有适应所有场景的前端框架?
2. 目前的世界上,有经验的Java开发人员更充裕,还是前端更充裕?
3. 为什么多数Java开发人员害怕写JS?

我自己来回答吧。

1. 在任何领域都不存在通用方案,所谓通用,也就意味着对某些特定场景缺乏关照。Angular的出现,并非是为了跟jQuery竞争,而是为了迎合企业应用领域,以及一些管控类项目的场景。这些场景有它的特殊性,对他们来说,模型层的复杂度高于普通网站,之前那种混杂DOM操作和业务逻辑的代码更不易管控,从前端开发者的角度是不太容易意识到这些问题的,他不知道在这类场景下,谈论某种库或者某个框架都没有意义,只有整体的一揽子解决方案才有意义。刚才这个文中所提到的移动端的考虑,更是太强人所难,到现在为止,哪个框架敢说自己成功解决了在PC版的Web和移动版之间的良好通用性?Vanilla?

2. 我在南京,在这里,能把Java写得规整,像模像样的码农至少几万个,前端写得同样规整有经验的,至少差两个数量级。这种情况下怎么办,不充分利用已有资源,坐着等天上掉馅饼吗?所以在现在这个阶段,必然有很大一部分Java开发人员要去写JS。

3. 多数Java开发人员为什么害怕写JS?原因很简单,他并不怕写纯逻辑,而是怕写DOM操作代码。这些东西对他来说很烦闷,而且JS代码太过缺乏约束,也让他很无所适从。之前很多企业软件使用ExtJS这样的框架,用写Java的方式来写Web前端,这种开发人员严格来说还是算Java开发人员,不能算前端。

ExtJS为什么能被这些人接受,是因为它避免了对DOM的直接操作,所有东西都转化为逻辑了,同理,如果一个框架能避免他们接触DOM,但是又比ExtJS优点多,为什么不用呢?与ExtJS相比,Angular是不是离前端更近点?

所以我认为,Angular的存在,基本上不是抢jQuery的饭碗,而是要抢ExtJS的。回忆一下用ExtJS时候遇到的问题,界面部分的代码繁杂,UI人员基本没法参与,现在换成Angular,是不是好得多了,只要认真封装几个控件,万事大吉。至于说性能,难道ExtJS的性能很好吗?

如果要让Java人员参与前端开发,必须处理好几个问题:

1. 制定严格的代码规范,宁可死板,绝不宽松
2. 从架构层面把各种问题摆平,切分任务为小块,每个人只写特定小块代码
3. 在前端作分层,确保每一层代码的稳定
4. 跟真正懂前端的人一起把HTML、样式、控件好好规划

再回头看看,Angular给我们带来了什么?站在架构师的角度,你最害怕什么?害怕的是项目失控。怎么才能随时知道没有失控?分层,从下往上,逐次确保每个层面的稳定可靠,最上面的层出了问题,修复的代价最小。从这个角度出发,必须优先保证模型和业务逻辑不出问题。

Angular能让你把可控的东西一路往上推到很极端的地方,除了特别薄的表面,其他所有东西都纳入掌控,然后切切分分,丢给Java码农去搞,然后转身去跟真的懂前端的少数人一起把外面那层皮做好,协作一定是很愉快的。

刚才这些,我解释了为什么企业级的开发人员和架构师对Angular如获至宝。现在谈谈文中提到的其他几个问题:

1. 性能

这个问题一针见血,确实有性能问题,但我们提到,这个框架的主要应用场景还是企业应用领域,只要它不把范围扩大,不会有什么影响,因为在这类领域,这种程度的启动性能问题压根就不敏感。

在实际开发中,一定会遇到一些其他性能问题,比如大数组,复杂对象,这些才是真正有影响的,需要用不同的手段来优化。这个我后面专门写文章讲。

那么,为什么我认为这些不是关键问题呢?是因为目前的企业前端开发领域,最核心问题压根不是性能,而是生产力,生产力处于严重低下的地步。收割机出来之前,人们手工收割,一行一行割过去,有了收割机,一次割一片。如果考虑细节效率,肯定收割机不如手工,因为收割机很容易漏收,掉在地上的也不少。那我们难道就因此坚守老的收割方式?火车出现之后,驾驶马车的看不惯它,问题是,你怎么知道你现在所谓的那些前端代码风格就是好的,高效的?改变个代码风格,一定错了吗?

况且,Angular的绝大多数性能问题处于非常上层的位置,这一层是有很多机会优化的,可以不影响业务代码的实现。

2. 移动端

虽然目前也存在Ionic这样的框架,但我自己对这方面还是比较保留,也从来不会推荐人使用Angular开发移动端的东西,除非只是表单类的系统。

事实上,我们目前也并没有哪个框架真正解决了移动端高效生产,或者哪怕是开发得稍微舒心一点的问题,在这个事情上,大家只是五十步笑一百步。

3. Angular 2.0

与作者的观点相反,我对2.0非常看好,认为它基本不会失去企业开发者的支持,同时会赢得更多移动端开发者。

在企业应用领域,甚至存在过GWT这么奇怪的东西,也就是完全用Java写界面,然后编译到HTML和JS去,而且这个东西在这个领域还是有很多人认同。Flex和Silverlight也同样有很大的用户群,基于这个,凭什么说AtScript就不会流行?我相信会有很多Java开发人员宁可写AtScript,也不愿意写JS,更何况,ng2.0只是自己用AtScript实现,业务开发人员一样可以很好地用JS开发啊。

关于这一块,我的两篇文章也说得很清楚了:

有关Angular 2.0的一切 · Issue #8 · xufei/blog · GitHub

浴火重生的Angular · Issue #9 · xufei/blog · GitHub

题外话:在现实中,我们碰到很多处理不好前端代码的项目,根本原因在于两点:

前端开发者缺乏架构意识
项目负责人和架构师没有足够的前端知识

这两点不解决,用什么框架都一定做成渣。
当web业务进入红海,用户不再满足于基本的功能需求,开始追求更好的体验的时候,富前端的web应用需求变得旺盛之时,前端框架才有意义。

传统服务端渲染的网站来说,使用jQuery加上各种插件就足以应付,而且可以更灵活的与Server端进行配合。代码量基本是可控的,大多数复杂逻辑都可以依赖插件来完成。

但是对于富前端应用,插件虽然仍然可以解决诸如轮播图、图表、编辑器等较复杂的通用逻辑,但是大量本由Server端处理的应用层逻辑前移,这些逻辑并不通用,不适合封装成插件,在没有框架的情况下,往往一个充斥大量业务逻辑、好几千行的JS文件就诞生了。

前端模块化和前端框架都是基于富前端应用的需求才应运而生的,它们并不试图解决传统类库&插件时代的浏览器兼容和页面效果,而是试图解决前端代码的合理组织和分层、降低代码量、提高可维护性。

这一点上讲,Angular是成功的,作为最负盛名的前端框架,它解决了富前端应用的代码失控问题,基于Angular的组件生态圈也让多人协作快速搭建应用成为可能。较为统一的编程模式更有规律可循,让项目交接变得更轻松了。不排斥传统的jQuery开发模式,兼容到IE8也让更多的开发者可以接受。

总而言之,Angular可以解决富前端应用中可能的代码失控和难以维护的风险,Angular本身存在的一些bugs或者使用中遇到的问题也往往可以暂时采用传统方式绕过去,对于富前端应用来说,使用Angular或者类似的前端框架总的来说是利大于弊的。

但是对于前端开发者来说,Angular却并非福音,一方面如文章所言,前端框架的流行让后端写出还不错的前端展现成为了可能,Bootstrap解决了后端在CSS上的弱点、而Angular-Bootstrap让后端也可以写出原来只有前端高手才能搞定的富前端应用。像Rails这样的后端框架还丧心病狂的集成了assets pipeline这样的前端工程化组件。可以说,现在一个其它端的工程师依赖这些工具可以轻松的transfer到前端岗位上来。

而且前端工程师面前也出现了两条路,一条是选择精通各种DOM规范,JavaScript API、HTTP协议、算法,一条是选择精通Angular、Ember、Bootstrap等应用层框架,可以高效的搭建应用,解决或者规避开发过程遇到的各种坑。

显然,大多数人更想走第一条道路,但现实中,绝大多数人只能走第二条。正如多数人都想成为高富帅,但最后基本都是屌丝一样。毕竟选择第二条,工作好找,不愁失业,学习成本低,就像满大街精通SSH,精通CI框架一样。框架的出现会让很多工程师失去接触底层实现的机会,尤其是身处业务密集的公司。

所以前端工程师本能抗拒Angular我认为是很正常的,毕竟关系到职业发展和切身利益,但是问题在于,不可能存在一套既足够灵活,可以接触底层,又可以控制复杂应用中项目失控风险的东西。不论前后端都是这样,灵活,开放底层的框架必然功能不强&使用不便,功能强大的框架必然底层开放度低,重而低效。

所以前端框架的发展是必然的,因为富前端应用的需求在这里摆着,没有Angualr也会有Bngular,Angualr有它的缺点,以后或许会被更好的框架取代,但是整体的趋势我认为不会改变。前端工程师必须学会在项目中接受框架条条框框的存在,可以选择的只是框架的重量级而已。引个jQuery随便写的时代该渐渐过去了。
为什么?