我为什么选择Angular 2？| TW洞见
今日洞见
文章作者来自ThoughtWorks：王志成。本文封面来自网络。
本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。
没有选择是痛苦的，有太多的选择却更加痛苦。而后者正是目前前端领域的真实写照。新的框架层出不穷： 它难吗？它写得快吗？可维护性怎样？运行性能如何？社区如何？前景怎样？好就业吗？好招人吗？组建团队容易吗？
面对每一个框架都得评估数不清的问题，直到耗光你的精力。这种困境，被称为“布利丹的驴子” —— 一只驴子站在两堆看似完全相同的干草堆中间，不知道如何选择，最终饿死了。
当然，那只是一个哲学寓言。现实中，大多数人采用了很简单的策略来破解它：跟风，选择目前最流行的那个。这是一个低成本高收益的策略， 不过也有风险：成为现实版的《猴子下山》。最理想的方案还是要看出这两堆“干草”之间的差异，选择更适合自己的那个。
本文就将带你了解Angular 2这个“干草堆”的各种细节。
ALL-IN-ONE
不管是1还是2，Angular最显著的特征在于其整合性。它是由单一项目组常年开发维护的一体化框架， 涵盖了M、V、C/VM等各个层面，不需要组合、评估其它技术就能完成大部分前端开发任务。 这样可以有效降低决策成本，提高决策速度，对需要快速起步的团队非常有帮助。
让我们换一种问法吧：你想用乐高搭一个客厅，还是买宜家套装？
Angular 2就是前端开发领域的“宜家套装”，它经过精心的前期设计，涵盖了开发的各个层面，层与层之间都经过了精心调适， 是一个“开箱即用”的框架。
当然，你可能还记着Angular 1带给你的那些快乐以及……痛苦。这是有历史原因的。由于它是从一个用来做原型的框架演化而来的， 加上诞生时间很早(2009年，作为对比，jQuery诞生于2006年)，生态不完善，连模块化机制都得自己实现 （这就是angular.module的由来，也是Angular 2中抛弃它的理由）。在长达七年的演化过程中，各种进化的遗迹非常明显，留下了不少“阑尾”。
但Angular 2就不同了，它的起点更高，整合了现代前端的各种先进理念，在框架、文档、工具等各个层面提供了全方位的支持。 比如它的“组件样式”能让你在无需了解CSS Module的前提下获得CSS Module的好处，它的“Starter工程”能让你在无需了解Webpack的前提下获得Hot Module Replacement等先进特性，它能让你从Web Worker(你知道这是什么吗？)中获得显著的性能提升。
你只管在前台秀肌肉吧！剩下的，让Angular在幕后帮你搞定！
逃离“版本地狱”
如果是一两个人开发一个预期寿命不到一年的系统，那么任何框架都可以胜任。但，现实中我们都把这种系统称之为“坑”。 作为一个高度专业、高度工程化的开发组，我们不能把“坑”留给友军。这些坑中，最明显的就是“版本地狱”。
想象一下，你仅仅升级了库的小版本号，原来的软件就不能用了，损坏了N处单元测试以及M个E2E场景。 这种情况对于开发组来说简直是一个噩梦 —— 毕竟，谁也不想做无用功，更何况是一而再、再而三的。 或者，它每次小的改动都会修改大版本号 —— 对，我就是不向后兼容，你能咋地？你所能做的就是每一次决定升级都如临大敌， 不但要小心翼翼的升级这个库本身还要升级与它协作的几乎所有库。
可见，乱标版本号可能会让使用者付出巨大的代价。这不但体现在工作量上，还会体现在研发团队的招募与培养上，想象一下， 对于在小版本之间都不兼容的框架，研发团队都需要记住多少东西？那简直是噩梦！
但是，版本号的问题在业内早就有了事实性标准，那就是SemVer语义化版本标准。 唯一的问题是，作为框架/库的作者，遵循SemVer标准需要付出的努力是巨大的。是否愿意付出这些代价， 是一个框架(及其开发组)是否成熟的重要标志。
Angular就是这样一个框架，其开发组曾作出的努力是有目共睹的。如果你是从Angular 1.2开始使用的，那么你为1.2所写的代码 都可以毫无障碍的迁移到最新的1.5版，新的版本只是引入了新特性，而没有破坏老特性。 这是因为Angular开发组写了大量单元测试和E2E测试，借助CI来保障这种平滑过渡。只有在从1.0到1.2的迁移过程中(1.1一直是beta，忽略不计)， 出现了一系列破坏性变更，这些变更被明确的记录在文档中，并且解释了做出这些变更的理由 —— 大多数是因为提升前端代码安全性。 即使你恰好遇到了这些破坏性变更，它也会给出明确的错误提示。
这些必要而无聊的工作，正是帮助我们逃离“版本地狱”的关键。是否愿意做这些无聊而琐碎的工作，是一个框架的开发组是否成熟、专业的关键特征。
模块化的技术
虽然Angular是一个ALL-IN-ONE的框架，但这并不妨碍它同时是一个灵活的框架。还记得OCP(开闭原则)吗？ 一个好的设计，对扩展应该是开放的，对修改应该是关闭的。
Angular 2很好的践行了OCP原则以及SoC(关注点分离)原则。
它非常有效的分离了渲染与交互逻辑，这就让它可以很好的跟包括React在内的渲染引擎搭配使用，除此之外，它还可以使用内存渲染引擎，以实现服务端渲染；还可以使用Native渲染引擎， 以编译出真正的原生程序(NativeScript)。
它还分离了数据供应与变更检测逻辑，从而让它可以自由使用包括RxJS以及ImmutableJS在内的第三方数据框架/工具。
不仅如此。
在Angular 1和Angular 2中最具特色的应该算是依赖注入(DI)系统了，它把后端开发中用来解决复杂问题、实现高弹性设计的DI技术引入了前端。Angular 2中更是通过引入TypeScript赋予它更高的灵活性和便利性。
不过，Angular 2并没有敝帚自珍，把它跟框架本身紧紧黏结在一起，而是把它设计成了一个独立可用的模块。 这就意味着，无论你正在使用什么前端框架，甚至NodeJS后端框架，都可以自由使用它，并从中获益。
开放的心态
当年的浏览器大战，让人记忆犹新，Chrome的出品商Google和IE的出品商微软正是浏览器大战的两大主角。
俗话说：没有永远的朋友，也没有永远的敌人，只有永远的…… 精益求精。
正是在这样的“俗话”指导下，Google与微软相逢一笑泯恩仇，撤销了很多针对彼此的诉讼，甚至在一些领域开始合作。 而实际上，在他们公开和解之前，就已经开始公开合作了，其契机就是Angular 2。
这就要扯出一点小八卦了。
在Angular 2开发的早期阶段，由于传统JS(ES5)以及当时的ES6草案无法满足项目组的开发需求，项目组有点烦。 后来有人灵机一动开发了一种叫做AtScript的新语言，它是什么呢？一个带类型支持和Annotation支持的升级版JS。 其实在类型支持方面，TypeScript早就已经做了，而且那时候已经比较成熟，唯一的遗憾是不支持Annotation， 也就是像Java中那样通过@符号定义元数据的方式。
Angular开发组就这样孤独的走过了一小段时间，后来也不知道怎么这两个欢喜冤家就公然牵手了。 总之，最后的结果是：TypeScript中加入了Annotation特性，而Angular放弃了AtScript改用TypeScript。
这次结合无论对两大厂商还是对各自的粉丝，都是一个皆大欢喜的结局，称其为“世纪联手”也不为过。 此后，Google与微软不再止于暗送秋波，而是开始了一系列秀恩爱的动作。无论如何，对于开发者来说，这都是一个好消息。
软粉们可能还记得在6.1的微软开发者大会上，微软曾公开提及Angular 2。事实上，TypeScript目前虽然已经相当完备，但应用度仍然不高。 就个人感觉来说，Angular 2将是TypeScript的一个杀手级应用。TypeScript如果当选TIOBE年度语言，Angular 2的推出功不可没。
为什么我要特意插播这段故事呢？那是因为我认为一个产品的未来最终取决于开发组的未来，而不是相反。 软件的本质是人！有一个心态开放、讲究合作、勇于打破陈规陋习的开发组，才是框架给人信心的根本保障。
……
阅读下半部分内容&文中蓝色字体对应链接请点击【阅读原文】
- 小编推荐 -
《关于前端的思考：AngularJS 2.0以及前后端边界 | TW洞见》HOT!!!
《Build 2016：细数给开发者的福利 | TW洞见》HOT!!!
回复201501-201605，获取当月精彩洞见合辑
如：想看5月精彩洞见合辑，请回复 201605
若你想去 TW洞见网站阅读所有洞见文章，复制网址在浏览器打开：insights.thoughtworkers.org
阅读下半部分内容&文中蓝色字体对应链接请点击【阅读原文】