爲何選擇Angular 2？

沒有選擇是痛苦的，有太多的選擇卻更加痛苦。然後者正是目前前端領域的真實寫照。新的框架層出不窮：它難嗎？它寫得快嗎？可維護性怎樣？運行性能如何？社區如何？前景怎樣？好就業嗎？好招人嗎？組建團隊容易嗎？

每個框架都得評估數不清的問題，直到耗光你的精力。這種困境，被稱爲「布利丹的驢子」 —— 一隻驢子站在兩堆看似徹底相同的乾草堆中間，不知道如何選擇，最終餓死了。

固然，那只是一個哲學寓言。現實中，大多數人採用了很簡單的策略來破解它：跟風，選擇目前最流行的那個。這是一個低成本高收益的策略，不過也有風險：成爲現實版的《猴子下山》。最理想的方案仍是要看出這兩堆「乾草」之間的差別，選擇更適合本身的那個。

本文就將帶你瞭解Angular 2這個「乾草堆」的各類細節。

ALL-IN-ONE

無論是1仍是2，Angular最顯著的特徵就是其整合性。它是由單一項目組常年開發維護的一體化框架，涵蓋了M、V、C/VM等各個層面，不須要組合、評估其它技術就能完成大部分前端開發任務。這樣能夠有效下降決策成本，提升決策速度，對須要快速起步的團隊是很是有幫助的。

讓咱們換一種問法吧：你想用樂高搭一個客廳，仍是買宜家套裝？

相關廠商內容

羅輯思惟Go語言微服務改造完整過程

Netflix的將來IT架構模型：Serverless

阿里菜鳥全球跨域RPC架構實踐痛點難點

區塊鏈浪潮來襲，企業技術leader如何理性抉擇？

2018，若是不懂這項技術，你可能將被淘汰

相關贊助商

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在幕後幫你搞定！

模塊化的技術

雖然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後端框架，均可以自由使用它，並從中獲益。

全生命週期支持

除非你打算寫一個一次性應用，不然軟件的生命週期會很長。宏觀來看，真正的挑戰來自多個方面，並且在不斷變化。

開始的階段，咱們須要很是快速的創建原型，讓它跑起來，引入最終用戶來試用，這個時候，挑戰來自開發速度以及可複用資產。

以後，會創建一個逐漸擴大的項目組，來完善這個原型的功能。主要的挑戰是讓這個原型經過重構不斷進行演化，特別是在演化的後半個階段，產品須要保持隨時能夠上線的狀態。但技術上的挑戰那都不是事兒！關鍵是人。

如何讓新人快速融入項目組，貢獻生產力？這可沒那麼簡單。「你先去學xxx 0.五、yyy 0.九、zzz 5.3...還要了解它們先後版本之間的差別，我再給你講代碼」，這種話，我可說不出口。一個優秀的框架須要對分工提供良好的支持，每一個人均可以先從一些簡單任務開始，逐步的從修改一個文件擴大到修改一個目錄再到獨立實現一個特性。

有了這種分工，每一個團隊成員就能夠從一個成功走向一個更大的成功。這就須要框架在設計上具備良好的局部性：你能夠放心大膽的修改一部分，而不用擔憂影響另外一部分。你能夠只修改CSS，能夠只修改HTML，能夠只修改TS/JS，而不用擔憂本身的修改破壞了其餘部分。而Angular 2經過聲明式界面、組件樣式以及獨立模板文件等對這種安全感提供了有力的保障。

再而後，若是你的軟件順利的進入了線上維護階段，那麼恭喜你，你終於迎來真正的大Boss了！這個大Boss就是可維護性。Angular開發組有不少程序員來自Google，若是要問誰的軟件維護經驗最豐富，Google和微軟必然名列前茅。微軟經過TypeScript的強類型機制體現了本身的經驗，而Google則經過將OCP、SoC、SRP等一系列軟件設計原則融入Angular體現了本身的經驗。具體技術上則體現爲：DI、生命週期鉤子、組件等等。

最後，若是你的軟件完成了歷史使命須要逐步退出，是否是就能鬆口氣了？不行，你還得繼續留人維護它。若是你選擇的是一個閉源的或某個社區很羸弱的開源技術，你就把之前的主力架構師、資深程序員留下來繼續維護它吧。或者你就得鼓起勇氣跟用戶說：大家玩兒，我先走了。而Angular是一個大型開源項目，並獲得了Google的鼎力支持。即便經歷過Angular 2項目組初期的公關失敗，它仍然有着其它競品沒法企及的繁榮社區 —— 不管在全球仍是在中國。顯然，不管是對傳統社區資源的繼承，仍是對新社區資源的開拓，咱們都有理由相信，Angular社區仍將一如既往地繁榮。至少，若是你不想讓本身的軟件創建在一大堆由我的維護的核心庫上，那麼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的開發組已經證實了它值得你信任！

碰見將來的標準

編程領域，創新無處不在。但對一個工程團隊來講，最可貴的是標準。標準意味着：

• 招人容易。由於標準的東西會的人最多，並且人們願意學它 —— 由於知道學了就不會浪費。
• 養人容易。由於網上有不少教程可用，即便不得已本身作教程，性價比也是最高的。
• 換人容易。標準就意味着不是私有技術，一我的離開了，就能用另外一我的補上，而不會出現長期空缺，影響業務。

可是，標準永遠會比創新慢一拍或N拍。這就意味着若是你追新，那麼在得到技術上的收益的同時，也要付出工程上的代價。當然，二者不可兼得，可是仍是有一些策略可以調和二者的。最簡單的策略就是：碰見將來的標準。

所謂將來的標準，就是某個標準的草案，它頗有但願成爲將來的標準，這表明了業界對某項技術的承認，因而，即便它還不成熟，人們也願意爲之投資。好比雖然Google曾經提出過N種自有技術，包括SPDY、Gears、OGG等，但卻並無把它們變成私有技術，而是對社區開放以及併入W3C的標準草案。

Angular 2採用的就是這種策略。它所參照的標準草案比較多，一個是WebWorker，它藉助WebWorker來把繁重的計算工做移入輔助線程，讓界面線程不受影響；另外一個是WebComponents，Angular 2的組件化體系就是對WebComponents的一種實現；最後是CSS scoping，如今雖然市面上有了不少CSS模塊化技術，但事實上最終仍是會被統一到CSS Scoping標準上，屆時，若是:local等關鍵字沒法進入標準，就會成爲私有技術。而Angular 2選擇的方式是直接實現CSS scoping標準草案，好比:host、:host-context等。顯然，採用這種策略，「碰見將來的標準」的成功率會高得多。

能夠看到，Angular 2的設計哲學中貫穿着對標準化的熱烈擁抱，這是我判斷它將贏得將來的另外一個信心來源。

速度與激情

Angular 2終於擺脫了舊的技術框架束縛，開始了對速度的極致追求。在Angular 1中，雖然絕大多數場景下性能都不是問題，不過仍是由於其代碼中存在的一個用來實現髒檢查的三重循環而飽受抨擊 —— 彷佛真有人能感覺到30毫秒和100毫秒的差別似的。

不過，有軟肋老是不太好。因而，在Angular 2中，經過從新設計和引入新技術，從原理上對速度進行了提高，據官方之前提供的一個數聽說是把「變動檢測」的效率提高了500%。

它在「變動檢測」算法上作了兩項主要的改進：

• 在設計上，把之前的「多輪檢查、直到穩定」策略改爲了「一輪檢查、直接穩定」策略。

  固然，這會對本身的代碼產生必定的限制，但實際上只在有限的少數幾個場景下才會遇到這個限制，並且官方文檔中也給出了明確的提示。

• 在實現上，把「變動檢測」算法移入了由WebWorker建立的輔助線程中執行。

  現代的家用電腦不少都已是多核超線程的，可是瀏覽網頁時實際上沒法充分利用所有線程，而WebWorker提供了一個新的機制，

  讓一些相對繁重的計算工做運行在輔助線程中，等執行完了再通知主線程。即便你不明白WebWorker的工做原理，

  至少也能知道Ajax請求是不會阻塞界面響應的，WebWorker也同樣。

除此以外，Angular還對數據源進行了抽象，你徹底能夠用ImmutableJS來做爲Angular的數據源，得到其在提高「變動檢測」速度方面的全部優點。

除了「變動檢測」外，Angular以及全部前端SPA程序，都有一個通病：首次加載太慢，要下載完全部js和css才能渲染出完整的界面來。React經過虛擬DOM解決了此問題，而Angular 2則經過獨立的服務端渲染引擎解決了這個問題。咱們前面說過，Angular 2把渲染引擎獨立了出來，所以能夠在NodeJS中實現服務端的內存渲染。所謂內存渲染就是在內存中把DOM結構渲染出來併發回給瀏覽器，這樣，客戶端不須要等JS代碼下載完就能夠顯示出完整的界面了。這種分離還帶來了另外一個好處，那就是SEO。SEO一樣是傳統SPA的一個難點，它和服務端渲染是同一個問題的兩個方面，所以隨着服務端渲染的完成，SEO問題也被順便解決了。

讓你無縫升級

Angular 2開發組在早期階段曾犯下一個嚴重的公關錯誤：過早宣佈不兼容Angular 1，也不提供從Angular 1到2的升級方案。

這讓Angular 2開發組付出了沉重的代價，可謂傷透了粉絲的心。做爲技術人員，這種失誤當然是能夠理解的，但卻須要付出更多的努力來彌補它。而Angular 2確實這麼作了。

在Angular 2中，開發組提供了一個UpgradeAdapter類，這個升級適配器讓Angular 1.x的全部部件都能和Angular 2.x中的全部部件協同工做。

而最牛的地方在於，它讓你能夠一個文件一個文件的逐步升級到Angular 2，而在整個升級過程當中，應用能夠繼續在線上跑！看着神奇嗎？其實也算不了啥，Google作這種事早就是輕車熟路了。這只不過是對Angular開發組出色的工程化開發能力的一點小小證實而已。

不過，既然如此，當初又何須急匆匆宣佈不兼容呢？可見，再出色的工程團隊，若是缺乏了和社區溝通的產品運營技巧，也會付出巨大代價。但願Angular開發組之後能謹言慎行，多用行動來平息質疑。

幕後 —— 當Google牽手微軟

當年的瀏覽器大戰，讓人記憶猶新，Chrome的出品商Google和IE的出品商微軟正是瀏覽器大戰的兩大主角。

俗話說：沒有永遠的朋友，也沒有永遠的敵人，只有永遠的…… 精益求精。

正是在這樣的「俗話」指導下，Google與微軟相逢一笑泯恩仇，撤銷了不少針對彼此的訴訟，甚至在一些領域開始合做。而實際上，在他們公開和解以前，就已經開始公開合做了，其契機就是Angular 2。

這就要扯出一點小八卦了。

在Angular 2開發的早期階段，因爲傳統JS（ES5）以及當時的ES6草案沒法知足項目組的開發需求，項目組有點煩。後來有人靈機一動開發了一種叫作AtScript的新語言，它是什麼呢？一個帶類型支持和Annotation支持的升級版JS。其實在類型支持方面，TypeScript早就已經作了，並且那時候已經比較成熟，惟一的遺憾是不支持Annotation，也就是像Java中那樣經過@符號定義元數據的方式。

Angular開發組就這樣孤獨的走過了一小段兒時間，後來也不知道怎麼這兩個歡喜冤家就公然牽手了。總之，最後的結果是：TypeScript中加入了與Annotation類似的Decorator特性，而Angular放棄了AtScript改用TypeScript。

此次結合不管對兩大廠商仍是對各自的粉絲，都是一個皆大歡喜的結局，稱其爲世紀聯手也不爲過。此後，Google與微軟再也不止於暗送秋波，而是開始了一系列秀恩愛的動做。不管如何，對於開發者來講，這都是一個好消息。

軟粉們可能還記得在6.1的微軟開發者大會上，微軟曾公開說起Angular 2。事實上，TypeScript目前雖然已經至關完備，但應用度仍然不高。就我的感受來講，Angular 2將是TypeScript的一個殺手級應用。TypeScript若是當選TIOBE年度語言，Angular 2的推出功不可沒。

爲何我要特地插播這段兒故事呢？那是由於我認爲一個產品的將來最終取決於開發組的將來，而不是相反。軟件的本質是人！一個心態開放、講究合做、敢於打破陳規陋習的開發組，纔是框架給人信心的根本保障。

後端程序員的終南捷徑

前端程序員自沒必要說，由於有不少人就是靠Angular進入專業前端領域的。下面這段話主要寫給後端程序員。

無論是想學習新技術仍是出於工做須要，都有不少後端程序員對前端技術躍躍欲試。但面對前端讓人眼花繚亂的大量候選技術以及未知的概念，他們每每感受感受無所適從。若是你是其中的一員，那麼Angular能夠「治癒」你的選擇恐懼症。

正如前面所說，Angular是一個「ALL-IN-ONE」的框架，這就意味着你只要掌握了Angular就能夠完成大量的前端工做了。

這首先得益於它對各類技術的封裝，讓你不用關心它的實現細節。Angular隔離了瀏覽器的細節，大多數工做你甚至都不須要知道DOM等前端知識就能夠完成。

其次，Angular選擇了TypeScript做爲主語言。若是你是個C#程序員，必定會對它的語法感受似曾相識。沒錯，TypeScript和C#、Delphi有同一個「爹」 —— 傳奇人物Anders Hejlsberg。即便是Java程序員，也不會以爲陌生：強類型、類、接口、註解等等，無一不是後端程序員們耳熟能詳的概念。說到底，並無什麼前端語言和後端語言，在語言領域耕耘多年的Anders太熟悉優秀語言的共性了，他所作的取捨值得你信賴。

再次，Angular在前端實現了服務與依賴注入的概念。隨着前端需求的進一步膨脹，即便只算邏輯代碼，其需求複雜度也即將甚至已經遇上了大部分後端程序。因此，後端遇到過的挑戰前端也早晚會遇到，這正是後端程序員彎道超車的好機會，而依賴注入正是後端程序員的看家本領。

最後，Angular對團隊做戰提供了良好的支持，好比模板與代碼的分離、樣式表的局部化、組件化的設計、服務與依賴注入體系等。這些特性讓後端程序員能夠先專一於跟後端代碼最像的模型和交互邏輯部分，而把諸如樣式、模板等本身不擅長的部分交給隊友。