沒有選擇是痛苦的配名，有太多的選擇卻更加痛苦啤咽。而后者正是目前前端領(lǐng)域的真實寫照。新的框架層出不窮：它難嗎渠脉？它寫得快嗎宇整？可維護性怎樣？運行性能如何芋膘？社區(qū)如何鳞青？前景怎樣？好就業(yè)嗎为朋？好招人嗎臂拓？組建團隊容易嗎？
每一個框架都得評估數(shù)不清的問題习寸，直到耗光你的精力胶惰。這種困境，被稱為“布利丹的驢子” —— 一只驢子站在兩堆看似完全相同的干草堆中間霞溪，不知道如何選擇孵滞，最終餓死了。
當然威鹿，那只是一個哲學寓言√旮現(xiàn)實中，大多數(shù)人采用了很簡單的策略來破解它：跟風忽你，選擇目前最流行的那個幼东。這是一個低成本高收益的策略，不過也有風險：成為現(xiàn)實版的《猴子下山》科雳。最理想的方案還是要看出這兩堆“干草”之間的差異根蟹，選擇更適合自己的那個。
本文就將帶你了解Angular 2這個“干草堆”的各種細節(jié)糟秘。

ALL-IN-ONE

不管是1還是2简逮，Angular最顯著的特征就是其整合性。它是由單一項目組常年開發(fā)維護的一體化框架尿赚，涵蓋了M散庶、V、C/VM等各個層面凌净，不需要組合悲龟、評估其它技術(shù)就能完成大部分前端開發(fā)任務。這樣可以有效降低決策成本冰寻，提高決策速度须教，對需要快速起步的團隊是非常有幫助的。
讓我們換一種問法吧：你想用樂高搭一個客廳斩芭，還是買宜家套裝轻腺？
Angular 2就是前端開發(fā)領(lǐng)域的“宜家套裝”乐疆，它經(jīng)過精心的前期設(shè)計，涵蓋了開發(fā)中的各個層面贬养，層與層之間都經(jīng)過了精心調(diào)適挤土，是一個“開箱即用”的框架。
當然煤蚌，你可能還記著Angular 1帶給你的那些快樂以及……痛苦耕挨。這是有歷史原因的。由于它是從一個用來做原型的框架演化而來的尉桩，加上誕生時間很早（2009年筒占，作為對比，jQuery誕生于2006年）蜘犁，當時生態(tài)不完善翰苫，連模塊化機制都得自己實現(xiàn)（這就是angular.module的由來，也是Angular 2中拋棄它的理由）这橙。在長達七年的演化過程中奏窑，各種進化的遺跡非常明顯，留下了不少“闌尾”屈扎。
但Angular 2就不同了埃唯，它的起點更高，整合了現(xiàn)代前端的各種先進理念鹰晨，在框架墨叛、文檔、工具等各個層面提供了全方位的支持模蜡。比如它的“組件樣式”能讓你在無需了解CSS Module的前提下獲得CSS Module的好處漠趁，它的Starter工程能讓你在無需了解Webpack的前提下獲得Hot Module Replacement等先進特性，它能讓你從Web Worker（你知道這是什么嗎忍疾？）中獲得顯著的性能提升闯传。
你只管在前臺秀肌肉吧！剩下的卤妒，讓Angular在幕后幫你搞定甥绿！
模塊化的技術(shù)

雖然Angular是一個ALL-IN-ONE的框架，但這并不妨礙它同時是一個靈活的框架则披。還記得OCP(開閉原則)嗎共缕？一個好的設(shè)計，對擴展應該是開放的收叶，對修改應該是關(guān)閉的骄呼。
Angular 2很好的踐行了OCP原則以及SoC（關(guān)注點分離）原則共苛。
它非常有效的分離了渲染與交互邏輯判没，這就讓它可以很好的跟包括React在內(nèi)的渲染引擎搭配使用蜓萄，除此之外，它還可以使用內(nèi)存渲染引擎澄峰，以實現(xiàn)服務端渲染嫉沽；還可以使用Native渲染引擎，以編譯出真正的原生程序（NativeScript）俏竞。
它還分離了數(shù)據(jù)供應與變更檢測邏輯绸硕，從而讓它可以自由使用包括RxJS以及ImmutableJS在內(nèi)的第三方數(shù)據(jù)框架/工具。
不僅如此魂毁。
在Angular 1和Angular 2中最具特色的應該算是依賴注入(DI)系統(tǒng)了玻佩，它把后端開發(fā)中用來解決復雜問題、實現(xiàn)高彈性設(shè)計的DI技術(shù)引入了前端席楚。Angular 2中更是通過引入TypeScript賦予它更高的靈活性和便利性咬崔。
不過，Angular 2并沒有敝帚自珍烦秩，把它跟框架本身緊緊黏結(jié)在一起垮斯，而是把它設(shè)計成了一個獨立可用的模塊。這就意味著只祠，無論你正在使用什么前端框架兜蠕，甚至NodeJS后端框架，都可以自由使用它抛寝，并從中獲益熊杨。
全生命周期支持

除非你打算寫一個一次性應用，否則軟件的生命周期會很長墩剖。宏觀來看猴凹，真正的挑戰(zhàn)來自多個方面，而且在不斷變化岭皂。
開始的階段郊霎，我們需要非常快速的建立原型爷绘，讓它跑起來书劝，引入最終用戶來試用，這個時候土至，挑戰(zhàn)來自開發(fā)速度以及可復用資產(chǎn)购对。
之后，會建立一個逐漸擴大的項目組陶因，來完善這個原型的功能骡苞。主要的挑戰(zhàn)是讓這個原型通過重構(gòu)不斷進行演化，特別是在演化的后半個階段，產(chǎn)品需要保持隨時可以上線的狀態(tài)解幽。但技術(shù)上的挑戰(zhàn)那都不是事兒贴见！關(guān)鍵是人。
如何讓新人快速融入項目組躲株，貢獻生產(chǎn)力片部？這可沒那么簡單∷ǎ“你先去學xxx 0.5档悠、yyy 0.9、zzz 5.3…還要了解它們前后版本之間的差異望浩，我再給你講代碼”辖所，這種話，我可說不出口磨德。一個優(yōu)秀的框架需要對分工提供良好的支持奴烙，每個人都可以先從一些簡單任務開始，逐步的從修改一個文件擴大到修改一個目錄再到獨立實現(xiàn)一個特性剖张。
有了這種分工切诀，每個團隊成員就可以從一個成功走向一個更大的成功。這就需要框架在設(shè)計上具有良好的局部性：你可以放心大膽的修改一部分搔弄，而不用擔心影響另一部分幅虑。你可以只修改CSS炕倘，可以只修改HTML耍休，可以只修改TS/JS拆讯，而不用擔心自己的修改破壞了其他部分唁盏。而Angular 2通過聲明式界面、組件樣式以及獨立模板文件等對這種安全感提供了有力的保障毕荐。
再然后郁惜，如果你的軟件順利的進入了線上維護階段涡上，那么恭喜你浑玛，你終于迎來真正的大Boss了绍申！這個大Boss就是可維護性。Angular開發(fā)組有很多程序員來自Google顾彰，如果要問誰的軟件維護經(jīng)驗最豐富极阅，Google和微軟必然名列前茅。微軟通過TypeScript的強類型機制體現(xiàn)了自己的經(jīng)驗涨享，而Google則通過將OCP筋搏、SoC、SRP等一系列軟件設(shè)計原則融入Angular體現(xiàn)了自己的經(jīng)驗厕隧。具體技術(shù)上則體現(xiàn)為：DI奔脐、生命周期鉤子俄周、組件等等。

最后髓迎，如果你的軟件完成了歷史使命需要逐步退出栈源，是不是就能松口氣了？不行竖般，你還得繼續(xù)留人維護它。如果你選擇的是一個閉源的或某個社區(qū)很羸弱的開源技術(shù)茶鹃，你就把以前的主力架構(gòu)師涣雕、資深程序員留下來繼續(xù)維護它吧”蒸妫或者你就得鼓起勇氣跟用戶說：你們玩兒挣郭，我先走了。而Angular是一個大型開源項目疗韵，并得到了Google的鼎力支持兑障。即使經(jīng)歷過Angular 2項目組初期的公關(guān)失敗，它仍然有著其它競品無法企及的繁榮社區(qū) —— 無論在全球還是在中國蕉汪。顯然流译，無論是對傳統(tǒng)社區(qū)資源的繼承，還是對新社區(qū)資源的開拓者疤，我們都有理由相信福澡，Angular社區(qū)仍將一如既往地繁榮。至少驹马，如果你不想讓自己的軟件建立在一大堆由個人維護的核心庫上革砸，那么Angular毫無疑問是最好的選擇。
逃離“版本地獄”

如果是一兩個人開發(fā)一個預期壽命不到一年的系統(tǒng)糯累，那么任何框架都可以勝任算利。但，現(xiàn)實中我們都把這種系統(tǒng)稱之為“坑”泳姐。作為一個高度專業(yè)效拭、高度工程化的開發(fā)組，我們不能把“坑”留給友軍胖秒。這些坑中允耿，最明顯的就是“版本地獄”。
想象一下扒怖，你僅僅升級了庫的次版本號较锡，原來的軟件就不能用了，損壞了N處單元測試以及M個E2E場景盗痒。這種情況對于開發(fā)組來說簡直是一個噩夢 —— 畢竟蚂蕴，誰也不想做無用功低散，更何況是一而再、再而三的骡楼∪酆牛或者，它每次小的改動都會修改主版本號 —— 對鸟整，我就是不向后兼容引镊，你能咋地？你所能做的就是每一次決定升級都如臨大敵篮条，不但要小心翼翼的升級這個庫本身還要升級與它協(xié)作的幾乎所有庫弟头。
可見，亂標版本號可能會讓使用者付出巨大的代價涉茧。這不但體現(xiàn)在工作量上赴恨，還會體現(xiàn)在研發(fā)團隊的招募與培養(yǎng)上，想象一下伴栓，對小版本之間都不兼容的框架伦连，研發(fā)團隊都需要記住多少東西？那簡直是噩夢钳垮！
但是惑淳，版本號的問題在業(yè)內(nèi)早就有了事實性標準，那就是SemVer語義化版本標準饺窿。唯一的問題是汛聚，作為框架/庫的作者，遵循SemVer標準需要付出的努力是巨大的短荐。是否愿意付出這些代價倚舀，是一個框架(及其開發(fā)組)是否成熟的重要標志。

Angular就是這樣一個框架忍宋，其開發(fā)組曾作出的努力是有目共睹的痕貌。如果你是從Angular 1.2開始使用的，那么你為1.2所寫的代碼都可以毫無障礙的遷移到最新的1.5版糠排，新的版本只是引入了新特性舵稠，而沒有破壞老特性。這是因為Angular開發(fā)組寫了大量單元測試和E2E測試入宦，借助CI來保障這種平滑過渡哺徊。只有在從1.0到1.2的遷移過程中（1.1一直是beta，忽略不計）乾闰，出現(xiàn)了一系列破壞性變更落追，這些變更被明確的記錄在文檔中，并且解釋了做出這些變更的理由 —— 大多數(shù)是因為提升前端代碼安全性涯肩。即使你恰好遇到了這些破壞性變更轿钠，它也會給出明確的錯誤提示巢钓。
這些必要而無聊的工作，正是幫助我們逃離“版本地獄”的關(guān)鍵疗垛。是否愿意做這些無聊而瑣碎的工作症汹，是一個框架的開發(fā)組是否成熟、專業(yè)的關(guān)鍵特征贷腕。而Angular的開發(fā)組已經(jīng)證明了它值得你信任背镇！
遇見未來的標準

編程領(lǐng)域，創(chuàng)新無處不在泽裳。但對一個工程團隊來說瞒斩，最難得的是標準。標準意味著：
招人容易诡壁。因為標準的東西會的人最多，而且人們愿意學它 —— 因為知道學了就不會浪費荠割。
養(yǎng)人容易妹卿。因為網(wǎng)上有很多教程可用，即使不得已自己做教程蔑鹦，性價比也是最高的夺克。
換人容易。標準就意味著不是私有技術(shù)嚎朽，一個人離開了铺纽，就能用另一個人補上，而不會出現(xiàn)長期空缺哟忍，影響業(yè)務狡门。
但是，標準永遠會比創(chuàng)新慢一拍或N拍锅很。這就意味著如果你追新其馏，那么在獲得技術(shù)上的收益的同時，也要付出工程上的代價爆安。固然叛复，兩者不可兼得，但是還是有一些策略能夠調(diào)和兩者的扔仓。最簡單的策略就是：遇見未來的標準褐奥。
所謂未來的標準，就是某個標準的草案翘簇，它很有希望成為未來的標準撬码，這代表了業(yè)界對某項技術(shù)的認可，于是版保，即使它還不成熟耍群，人們也愿意為之投資义桂。比如雖然Google曾經(jīng)提出過N種自有技術(shù)，包括SPDY蹈垢、Gears慷吊、OGG等，但卻并沒有把它們變成私有技術(shù)曹抬，而是對社區(qū)開放以及并入W3C的標準草案溉瓶。
Angular 2采用的就是這種策略。它所參照的標準草案比較多谤民，一個是WebWorker堰酿，它借助WebWorker來把繁重的計算工作移入輔助線程，讓界面線程不受影響张足；另一個是WebComponents触创，Angular 2的組件化體系就是對WebComponents的一種實現(xiàn)；最后是CSS scoping为牍，現(xiàn)在雖然市面上有了很多CSS模塊化技術(shù)哼绑，但事實上最終還是會被統(tǒng)一到CSS Scoping標準上，屆時碉咆，如果:local等關(guān)鍵字無法進入標準抖韩，就會成為私有技術(shù)。而Angular 2選擇的方式是直接實現(xiàn)CSS scoping標準草案疫铜，比如:host茂浮、:host-context等。顯然壳咕，采用這種策略席揽，“遇見未來的標準”的成功率會高得多。
可以看到谓厘，Angular 2的設(shè)計哲學中貫穿著對標準化的熱烈擁抱驹尼，這是我判斷它將贏得未來的另一個信心來源。
速度與**

Angular 2終于擺脫了舊的技術(shù)框架束縛庞呕，開始了對速度的極致追求新翎。在Angular 1中，雖然絕大多數(shù)場景下性能都不是問題住练，不過還是因為其代碼中存在的一個用來實現(xiàn)臟檢查的三重循環(huán)而飽受抨擊 —— 似乎真有人能感受到30毫秒和100毫秒的差異似的地啰。
不過，有軟肋總是不太好讲逛。于是亏吝，在Angular 2中，通過重新設(shè)計和引入新技術(shù)盏混，從原理上對速度進行了提升蔚鸥，據(jù)官方以前提供的一個數(shù)據(jù)說是把“變更檢測”的效率提升了500%惜论。
它在“變更檢測”算法上做了兩項主要的改進：
在設(shè)計上，把以前的“多輪檢查止喷、直到穩(wěn)定”策略改成了“一輪檢查馆类、直接穩(wěn)定”策略。當然弹谁，這會對自己的代碼產(chǎn)生一定的限制乾巧，但實際上只在有限的少數(shù)幾個場景下才會遇到這個限制，而且官方文檔中也給出了明確的提示预愤。
在實現(xiàn)上沟于，把“變更檢測”算法移入了由WebWorker創(chuàng)建的輔助線程中執(zhí)行。現(xiàn)代的家用電腦很多都已經(jīng)是多核超線程的植康，但是瀏覽網(wǎng)頁時實際上無法充分利用全部線程旷太，而WebWorker提供了一個新的機制，讓一些相對繁重的計算工作運行在輔助線程中销睁，等執(zhí)行完了再通知主線程供璧。即使你不明白WebWorker的工作原理，至少也能知道Ajax請求是不會阻塞界面響應的榄攀，WebWorker也一樣嗜傅。
除此之外金句，Angular還對數(shù)據(jù)源進行了抽象檩赢，你完全可以用ImmutableJS來作為Angular的數(shù)據(jù)源，獲得其在提升“變更檢測”速度方面的所有優(yōu)勢违寞。
除了“變更檢測”外贞瞒，Angular以及所有前端SPA程序，都有一個通渤寐：首次加載太慢军浆，要下載完所有js和css才能渲染出完整的界面來。React通過虛擬DOM解決了此問題挡闰，而Angular 2則通過獨立的服務端渲染引擎解決了這個問題乒融。我們前面說過，Angular 2把渲染引擎獨立了出來摄悯，因此可以在NodeJS中實現(xiàn)服務端的內(nèi)存渲染赞季。所謂內(nèi)存渲染就是在內(nèi)存中把DOM結(jié)構(gòu)渲染出來并發(fā)回給瀏覽器，這樣奢驯，客戶端不需要等JS代碼下載完就可以顯示出完整的界面了申钩。這種分離還帶來了另一個好處，那就是SEO瘪阁。SEO同樣是傳統(tǒng)SPA的一個難點撒遣，它和服務端渲染是同一個問題的兩個方面邮偎，因此隨著服務端渲染的完成，SEO問題也被順便解決了义黎。
讓你無縫升級

Angular 2開發(fā)組在早期階段曾犯下一個嚴重的公關(guān)錯誤：過早宣布不兼容Angular 1禾进，也不提供從Angular 1到2的升級方案。
這讓Angular 2開發(fā)組付出了沉重的代價轩缤，可謂傷透了粉絲的心命迈。作為技術(shù)人員，這種失誤固然是可以理解的火的，但卻需要付出更多的努力來彌補它壶愤。而Angular 2確實這么做了。
在Angular 2中馏鹤，開發(fā)組提供了一個類征椒，這個升級適配器讓Angular 1.x的所有部件都能和Angular 2.x中的所有部件協(xié)同工作。
而最牛的地方在于湃累，它讓你可以一個文件一個文件的逐步升級到Angular 2勃救，而在整個升級過程中，應用可以繼續(xù)在線上跑治力！看著神奇嗎蒙秒？其實也算不了啥，Google做這種事早就是輕車熟路了宵统。這只不過是對Angular開發(fā)組出色的工程化開發(fā)能力的一點小小證明而已晕讲。
不過，既然如此马澈，當初又何必急匆匆宣布不兼容呢瓢省？可見，再出色的工程團隊痊班，如果缺少了和社區(qū)溝通的產(chǎn)品運營技巧勤婚，也會付出巨大代價。希望Angular開發(fā)組以后能謹言慎行涤伐，多用行動來平息質(zhì)疑馒胆。
幕后 —— 當Google牽手微軟

當年的瀏覽器大戰(zhàn)，讓人記憶猶新凝果，Chrome的出品商Google和IE的出品商微軟正是瀏覽器大戰(zhàn)的兩大主角祝迂。
俗話說：沒有永遠的朋友，也沒有永遠的敵人豆村，只有永遠的…… 精益求精液兽。
正是在這樣的“俗話”指導下，Google與微軟相逢一笑泯恩仇，撤銷了很多針對彼此的訴訟四啰，甚至在一些領(lǐng)域開始合作宁玫。而實際上，在他們公開和解之前柑晒，就已經(jīng)開始公開合作了欧瘪，其契機就是Angular 2。
這就要扯出一點小八卦了匙赞。
在Angular 2開發(fā)的早期階段佛掖，由于傳統(tǒng)JS（ES5）以及當時的ES6草案無法滿足項目組的開發(fā)需求，項目組有點煩涌庭。后來有人靈機一動開發(fā)了一種叫做AtScript的新語言芥被，它是什么呢？一個帶類型支持和Annotation支持的升級版JS坐榆。其實在類型支持方面拴魄，TypeScript早就已經(jīng)做了，而且那時候已經(jīng)比較成熟席镀，唯一的遺憾是不支持Annotation匹中，也就是像Java中那樣通過符號定義元數(shù)據(jù)的方式。
Angular開發(fā)組就這樣孤獨的走過了一小段兒時間豪诲，后來也不知道怎么這兩個歡喜冤家就公然牽手了顶捷。總之屎篱，最后的結(jié)果是：TypeScript中加入了與Annotation相似的Decorator特性服赎，而Angular放棄了AtScript改用TypeScript。
這次結(jié)合無論對兩大廠商還是對各自的粉絲芳室，都是一個皆大歡喜的結(jié)局专肪，稱其為世紀聯(lián)手也不為過刹勃。此后堪侯，Google與微軟不再止于暗送秋波，而是開始了一系列秀恩愛的動作荔仁。無論如何伍宦，對于開發(fā)者來說，這都是一個好消息乏梁。
軟粉們可能還記得在6.1的微軟開發(fā)者大會上次洼，微軟曾公開提及Angular 2。事實上遇骑，TypeScript目前雖然已經(jīng)相當完備卖毁，但應用度仍然不高。就個人感覺來說，Angular 2將是TypeScript的一個殺手級應用亥啦。TypeScript如果當選TIOBE年度語言炭剪，Angular 2的推出功不可沒。
為什么我要特意插播這段兒故事呢翔脱？那是因為我認為一個產(chǎn)品的未來最終取決于開發(fā)組的未來奴拦，而不是相反。軟件的本質(zhì)是人届吁！一個心態(tài)開放错妖、講究合作、勇于打破陳規(guī)陋**的開發(fā)組疚沐，才是框架給人信心的根本保障暂氯。
后端程序員的終南捷徑

前端程序員自不必說，因為有很多人就是靠Angular進入專業(yè)前端領(lǐng)域的亮蛔。下面這段話主要寫給后端程序員株旷。
不管是想學**新技術(shù)還是出于工作需要，都有很多后端程序員對前端技術(shù)躍躍欲試尔邓。但面對前端讓人眼花繚亂的大量候選技術(shù)以及未知的概念晾剖，他們往往感覺感覺無所適從。如果你是其中的一員梯嗽，那么Angular可以“治愈”你的選擇恐懼癥齿尽。
正如前面所說，Angular是一個“ALL-IN-ONE”的框架灯节，這就意味著你只要掌握了Angular就可以完成大量的前端工作了循头。
這首先得益于它對各種技術(shù)的封裝，讓你不用關(guān)心它的實現(xiàn)細節(jié)炎疆。Angular隔離了瀏覽器的細節(jié)卡骂，大多數(shù)工作你甚至都不需要知道DOM等前端知識就可以完成。
其次形入，Angular選擇了TypeScript作為主語言全跨。如果你是個C#程序員，一定會對它的語法感覺似曾相識亿遂。沒錯浓若，TypeScript和C#、Delphi有同一個“爹” —— 傳奇人物Anders Hejlsberg蛇数。即使是Java程序員挪钓，也不會覺得陌生：強類型、類耳舅、接口碌上、注解等等，無一不是后端程序員們耳熟能詳?shù)母拍睢Ｕf到底馏予，并沒有什么前端語言和后端語言蔓纠，在語言領(lǐng)域耕耘多年的Anders太熟悉優(yōu)秀語言的共性了，他所做的取舍值得你信賴吗蚌。
再次腿倚，Angular在前端實現(xiàn)了服務與依賴注入的概念。隨著前端需求的進一步膨脹蚯妇，即使只算邏輯代碼敷燎，其需求復雜度也即將甚至已經(jīng)趕上了大部分后端程序。所以箩言，后端遇到過的挑戰(zhàn)前端也遲早會遇到硬贯，這正是后端程序員彎道超車的好機會，而依賴注入正是后端程序員的看家本領(lǐng)陨收。
最后饭豹，Angular對團隊作戰(zhàn)提供了良好的支持，比如模板與代碼的分離务漩、樣式表的局部化拄衰、組件化的設(shè)計、服務與依賴注入體系等饵骨。這些特性讓后端程序員可以先專注于跟后端代碼最像的模型和交互邏輯部分翘悉，而把諸如樣式、模板等自己不擅長的部分交給隊友居触。