AngularJS 为什么成功了?

[yafeilee]

写在前面的话
继上一篇总结之后, 觉得必须补充一下 AngularJS 与 Ionic 的技术性话题
于是, 连夜写了这第一篇.
讲述了 AngularJS 与其他对手之间的优与缺.
我有任何理解错误, 请指正.

AngularJS 的成败

AngularJS 在这两年时光里, 可谓是异军突出. 我们来看看 Google 搜索指数:

如果你可以顺利翻墙的话, 可以看看这个指数链接

现在, 可以说, AngularJS 在前端领域, 已经占据了主要的地位.

虽然它的诞生, 就像 JavaScript 一样带着那样或这样的毛病, 但依然大发光彩.

AngularJS 与 JavaScript, 在我看来, 都属于 2014 年度最佳框架(语言).

我们来详细谈谈它的优点与缺点.

全栈 VS 简单

有人说, AngularJS 太庞大了, 太复杂了, 根本就是发展方向错误. 实则不然, 相反, 我的观点是, 全栈解决方案远大于简单的方案.

既然我对 Rails 很熟悉, 我来举一个 Ruby 界的例子: Rails vs Sinatra. 一个是复杂到 Web 整站解决方案, 既包括了后端, 还包括了前端, 连打包, 压缩, 布署都帮你做好了. 而另一个则是简单到极致, 几行代码就可以写一个 Web 服务. 然而, Sinatra 永远无法打败 Rails, 只能处于小众圈子. 因为只要项目一大, 他们就要重新造一遍 Rails 的轮子.

这个时候, 大部分人需要的是全栈解决方案, 不是小而美的东西.

那么, 显而易见, BackboneJS 与 ReactJS 从这个竞争中出局了.

实际上, AngularJS 像 Rails 一样, 它内部的轮子是可自由替换的, 事实上, 全栈的背后也是以简单作为基础的.

思想的背后

EmberJS 是 AngularJS 强有力的对手, 有很多支持者, EmberJS 的核心实现也是从 Rails 学到了很多东西.

但为什么大家依然选择了 AngularJS, 我以为真正核心的原因只有一点: 一个框架的哲学思想.

貌似有点深奥, 实际上很简单: AngularJS 从一诞生, 就认定了一件事: 在 Web 世界里, 声明式语法要远远好于命令式语法. 从这一点, 就引出了 AngularJS 的主要特性:

1. 双向数据绑定
2. 永不操作 DOM

而 EmberJS, 一开始就是 Rails 在前端的实现, 当然很多概念不适用, 并且有些特性又不够, 而现在, 也是补了许多该有的特性, 比如正在开发中的 HTMLBars, View 层无法理解 DOM( HandleBars 只能理解字符串 )是一个硬伤, 这让 AngularJS 优势太明显了: 哲学概念单一, 便于理解. 而 EmberJS, 更像一个后端的思想的框架, 有点水土不服.

或者, 应该换个说法: AngularJS 就像官方想做的那样, 只是想扩展 HTML 语法, 而不得不造了一些概念. 而 EmberJS 则是为了实现而实现. 如果你深入使用, 自会明白我的意思.

易于上手

AngularJS 真的太容易上手了, 当你做过官网上的 Hello World 例子后, 你就会惊讶: 原来不会 JavaScript 也能写好 Web2.0.

而 Ember 则一开始就教你理解各种概念, controller, action, template, router. 等一等, 我们需要一步步向上爬.

但是, 没有银弹

随着前端项目的复杂度上升, jQuery 这种命令式语法已经无法管束整个项目的高质量推进. 但 AngularJS 也不是银弹.

我们俗话有讲: 进入一个世界, 往往会放弃另外的世界. 这放与 AngularJS 身上非常合适: 正是 AngularJS 想把它的哲学思想做到极致, 才会带来诸多新的问题:

1. 动态作用域问题
2. 依赖注入问题
3. digest loop 双向绑定性能问题
4. directives 不必要的复杂度

这几点, 相信你只要是 AngularJS 深入使用过都会遇到类似问题.

我们看中它的优点, 用它来开发极动感的 AngularJS 前端应用, 也须理解并避开它的缺点.

1. 动态作用域

由于 AngularJS 双向绑定的需要, 你必须给数据指派一个域( scope ), 就像 JavaScript 中的 function, 会将每个不同的域中的数据隔开开来. 但不同的是, JavaScript 或 Java 等拥有完整语言特性的语言, 它们的 scope 的行为是预定义的, 只有有限的几种. 而 scope 则不然, 你无法真正理解它, 就无法理解为什么在 ng-repeat 中修改绑定的值却对应 controller 中的值是无效的一样困惑不解. 但是, 好的是, 当你真正成为程序员时, 你就会豁然开朗.

2. 依赖注入问题

这个问题出现的原因也是由于 AngularJS 的哲学导致: 依赖概念要够简单. 开发者想了一个极取巧的方法: 利用参数的名字作为依赖注入的对象. 正是因为 JavaScript 的强大多变, 他们才能做的到.
然而, 新手们总是发现, 坑来了: 为什么压缩后代码就不能用了? 高手们说: 我们专门做了个轮子, 避免你打包出错. 新手们: 好牛X...

3. 双向绑定的性能问题

双向绑定的目的是大大提高我们开发者的效率, 却因为当今浏览器引擎的"缺陷"( 无法真正理解事件影响范围 ), 而只能采用最笨拙的思路:

只要有事件触发, 就全面执行一次所有的监听( watcher ), 如果监听中有新的值出现, 则再次执行所有的监听, 进行重新计算, 反复最多 10 次.

这里就不解释原理了. 简而易见, 这里可能有性能问题.

但经过测试, 只要绑定对象不超过 2000 次, 则每一次 loop 都不会超出 50 ms. 这个时间差对我们人眼是无感知的.

但我认为, 比起这一点潜在的性能问题( 而且是可以轻松调优的, chrome 下有很好用的插件 ), 我们还是值得去学习应用 AngularJS 的.

4. directives 不必要的复杂度

这个问题是唯一一个从设计上欠考虑的模块了. directives 是一个好东西, 你可以用它来封装各种 HTML 操作, 然后把它们做成组件. 这个特性太酷了.

本来, 一鼓做气, 就可以把 ReactJS 比下去, 可是, 由于设计缺失. 我们只能得到一个半成品:

1. 语法定义非常蛋疼
2. scope 在其中非常绕, 难于理解
3. parser, link 等对于普通开发人员暴露的东西太多, 而难于理解. 而问题是, 对于我们普通开发者而言, 这个 directives 特性是我们必修的.

总结

AngularJS 依然拥有不可比拟的优势, 占据前端开发框架之首也是理所当然. 但 AngularJS 第一代框架确实不够大气, 第二代框架又太超前, 我们也不得不像使用 JavaScript 那样"坑"的语言那样来使用 AngularJS 了. 因为, 我们确实找不到更满意的取代品了.

更为可喜的是, AngularJS 的测试框架设计的极为出色, 这也让它能够不断快速迭代, 也让我们写的应用更为健壮.

这也是我选择一个框架的原因之一.

ps: 我是技术达人李亚飞(微信号), 也欢迎关注我的博客: http://yafeilee.me

下面的留言有点乱了, 不要为喷而喷.

目前我收到最有价值的信息就是举几个例子, 当然可以, 在此之前, 我要说一点,

既然我写的是未来下一步的事, 当下肯定还没那么流行, 大家不要惊慌, 如果真的已经非常流行, 我这篇文章还有价值么.

国内例子:

Worktile: https://worktile.com, 2014年11年拿到千万级风投. 拥有超过 8万注册团队.

知乎专栏, 大家混知乎的话懂的.

我只是找到两个最广为人知的案例, 周边朋友们默默在用的人也增多.

国外例子多不胜举, 但最让我印象深刻是:

苹果的团队 Itune connect apple store : https://itunesconnect.apple.com/

都是深度应用.

上升指数仅供参考

[Dannytmp]

NG确实很坑人，绕来绕去，尤其是DIRECTIVE部分，简直蛋疼

[ityao]

爱它,就会觉得它的好, 恨他, 就只会记住它的坏

[otmb]

Go成功么?

[dcoder]

Google 搜索指数 只能证明关注度成功了，其实也就是 AngularJS team 能打广告...
这样吧，楼主举几个大公司的大项目，看看有 heavily 使用 AngularJS 的没？

就我看过的 AngularJS 的项目，其实最后只是用 AngularJS 当当 HTML template 和 简单 binding, 真要做复杂的，还是上一堆其他community (e..g JQuery 生态里) 的现成轮子. 这样和 AngularJS 本身设计得大二全是相悖的.

而且 AngularJS 2.0 号称是不兼容 AngularJS 1.0 的，AngularJS这不是坑是啥.

[FrankFang128]

成功了？

[guotie]

reactjs挺好，并没有出局啊

[CosWind]

我可能不会用AngularJs，但我一定会用Jquery

[crazyxin1988]

已经在生产环境准备拿掉angular，上react了

[bigzhu]

angular 已经被我替换为 vue.js 了…看不出哪里好

[coolicer]

关react毛事，它并不是MVC框架。我们也用angular，虽然写得挺烂。毕竟是第一次试验

[lolocoo]

@crazyxin1988 能简单说说原因么？

[tremblingblue]

才疏学浅，正在啃一个ng的大项目，说真的我觉得上手真的不是那么容易。。。

[coolicer]

有多少人是用来再喷的，其实如果要喷，随便什么都可以的，找个借口而已。最好什么不用写，这样就没有不足了。

[simo]

鉴于ag无法在低端团队中推广，培训和维护成本太高，故歪楼；）
羡慕楼主无后顾之忧的创业，祝早成

[crazyxin1988]

@lolocoo
angular 比较重，不太适合复杂的前段应用。在crm这种系统里用还 蛮好的～
当然react只是一个库，有点像jquery，小而美
当然也有缺点～
没人喷angular，只是在应用场景上要有取舍，不能盲从

[ixiaohei]

@coolicer 感觉喷子很多；反正我的感觉用angular蛮爽的，至少在我的项目里，省去了一堆堆的query dom绑定

[markyun]

感觉不怎么好

[otarim]

directive 语法确实很蛋疼，现在写 ui 转 react 了，非常舒服

[momowei]

不谁就是mvvm,说的这么神，wpf和flex5年前就有的东西。
有了gwt的经验，我不会用这玩意的，我个人看好backbone,react.

[loading]

搜索量不代表什么……
github项目数量才有价值，谁知道他们搜索的是不是因为掉坑里了不会爬出来而搜索救火的？

[JerryC]

从文章的情感，看出楼主是angular的铁杆粉啊

[robertlyc]

成功个屁

[steven_yue]

还有一个原因：它是google出的，自然很多人留意它，静下心理解它。小公司出的，如果稍微有点怪异，有些人用一下，就骂声一片，剩下没用过的人，也随声附和。

[robertlyc]

正是因为它是google的 所以才要格外当心

google在语言技术上 从来都是三天打鱼两天晒网 go半吊子 dart连半吊子都不算 angular臃肿不堪 gwt呵呵 你活在上世纪吗还在用java写javascript?

一句话 成功不是所谓的技术传教士说的算了

[robertlyc]

用知乎上的一句话说 不问是不是 直接问为什么的都是耍流氓

[leonlu]

楼主, 你数了这么多不好的东西, 竟然还在坚持忍下去, 是为什么呢...

我觉得这篇文章也出差不多的缺点, 但是这个PO主已然转向react了...

https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99

[xuwenmang]

语言之争，框架之争。。码农真的很累。

[hellogbk]

我最近在学习angularjs，只是为了用ionic

[pppanda]

普通的业务需求使用 jQuery + template 基本可以满足需求，引入 Angular.js 这种框架无疑增加了团队成本，但 Angular.js 的流行程度是毋庸置疑的，思想很赞。

[dyq917]

哪个熟悉，用哪个（快速开发）
哪个出来久，用哪个（坑已经被踩的差不多了，生态圈也相对更好）

[NemoAlex]

个人认为楼主写得很好
除了标题：AngularJS 离“成功”还远得很

[yafeilee]

@leonlu 这篇对 AngularJS 的缺陷讲的更细致, 写的很好.

[fyh1807008]

哈哈，还是喷的多。我也不爽ng好久了，把java的各种轮子硬上javascript ！

[learnshare]

用的多是因为能够解决一个大问题：让 Web 从展示型页面变成功能型页面。其中主要的就是模块化、组件化。

Angular.js 还在自我革命，目前的版本确实没那么好，等待后续版本就好了。

[sujin190]

ng对面对用户的项目来说还是太坑，优化很纠结，js原生代码简直难读死了，讲内部细节的资料也不多，不过这依赖注入不要太牛逼

[chloerei]

Dependency injection is not a virtue http://david.heinemeierhansson.com/2012/dependency-injection-is-not-a-virtue.html

[clino]

我猜google没多久可能就会放弃angularjs了,一两年吧

[lyric]

关键词都不一样，有什么好比较的。



比如搜 ember 相关的问题时，总会特意打 ember.js 吗？更多是 ember + 问题关键词

[htz]

呵呵，当你总想着该不该学的时候，黄花菜都凉了。

[yafeilee]

@lyric 上升指数确实有严重误导, 谢谢指正. 之前没有留意到.

[shajiquan]

没成功呢。我都没用它…………

[bolasblack]

番茄土豆网页版用的就是 AngularJS ，directive 定义起来确实有点麻烦，但绝大部分配置项平常都是用不到的，所以感觉还是可以的

[levey]

楼主拿 itunes connect 来举例真是黑Angular, 你要知道icloud.com 是用 SproutCore, 也就是 Ember.js 的前身.

[ianva]

directive 的问题很多，特别是 angular 的解决方案本身就是有点 hack 的拼起来的感觉，比如 directive 里的 controller 的 this，directive 的嵌套后的通信也是问题，而且本身的事件机制也不够强大，当一个项目够复杂，模块之间的通信越来越多的时候就会变的难维护

directive 本身作为一个 UI 交互的承载其本身对 UI 组件的支持并不够强大，相对于yui 的 widgets，ext 的一些组件来说，还有 react，真正带来是是自定义标签和对当前数据的操作的衔接，经常会看到一些库会自己定义一些基础的 widget 最组件做扩展，从这一点来说 directive 提供的支持太少

而对于组件来说 directive 其实非常不完善，因为 directive 不能提供一个组件的整个功能，所以一个 ui 组件很有可能需要一个 directive 还需要调用 service 去完成 api 的调用，比如我要在相应的逻辑弹出一个模态框，那必须是个 service，这意味着做组件的时候要考虑怎么用 directive 和 service，而没有一个官方的对组件统一的机制，从这点看就是大量脑补

虽然是做双向绑定，但在数据这块的支持也不够，没有 model 层的官方支持，没有官方的数据操作，在做大项目的时候问题很多。

angular 本身是一个经历了多年逐渐搭建起来的项目，使得 angular 的基础结构都很别扭，不如各种如 directive，service，filter 在创建的形式上都不一样，return 的东西各有各的规则，书写起来也挺费劲，虽然有各种的 generator，但你真正用的时候发现很多 generator 还要自己搞。
所以2.0 是 angular 不可避免的，但有带来一个问题，2.0 不向前兼容，而且2.0 准备用 atscript 这个语言，这个真不一定是什么好事，另外1.0 只维护2年，后面1.0 的社区支持未来将完全都过时了，包括组件，库，问答，等等，这个是 angular 未来非常大的问题，个人感觉大于 python2 -> python所存在的问题

angular 确实是个很好的框架，但本身存在这非常多的问题，可以说是很多坑，但整个开发效率确实会有很大提升，未来2.0或许是个好的开头

[otmb]

@yafeilee ng成功了么？怎么好多人说这货不靠谱呢？

[otmb]

真的太容易上手了？这货没那么容易吧?
楼主是想坑大家么：（

[otmb]

@clino 为何得出这个结论呢？

[clino]

@otmb 因为有另外一个也是google出产的polymer ( https://www.polymer-project.org/ ) ,包括了angularjs的功能,而且还有其他更多的东东,另外感觉 angularjs的实验性比较强
当然这个纯属个人猜测,可能是因为我不用所以唱衰它无压力...:D

[otmb]

@clino polymer是ng2吗？

[semicircle21]

@chloerei angularJs 和 Dependency injection 有什么关系?

[chloerei]

@semicircle21 Dependency injection 是 Angularjs 宣传的一个“特性”，但我觉得是一个“缺点”。