如何看2015年1月PeterPaulKoch对Angular的看法

2020-02-13 22:13:28

感谢邀请。早上看到阮一峰老师转发了这篇文章,中午手痒翻译了一份:[翻译]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.Angular2.0与作者的观点相反,我对2.0非常看好,认为它基本不会失去企业开发者的支持,同时会赢得更多移动端开发者。在企业应用领域,甚至存在过GWT这么奇怪的东西,也就是完全用Java写界面,然后编译到HTML和JS去,而且这个东西在这个领域还是有很多人认同。Flex和Silverlight也同样有很大的用户群,基于这个,凭什么说AtScript就不会流行?我相信会有很多Java开发人员宁可写AtScript,也不愿意写JS,更何况,ng2.0只是自己用AtScript实现,业务开发人员一样可以很好地用JS开发啊。关于这一块,我的两篇文章也说得很清楚了:有关Angular2.0的一切·Issue#8·xufei/blog·GitHub浴火重生的Angular·Issue#9·xufei/blog·GitHub题外话:在现实中,我们碰到很多处理不好前端代码的项目,根本原因在于两点:前端开发者缺乏架构意识项目负责人和架构师没有足够的前端知识这两点不解决,用什么框架都一定做成渣。

上一篇:如何评价201819赛季结束后的克里斯保罗
下一篇:江西:五一期间 南昌公交保险运送乘客521万余人次