標籤：

如何評價 Angular 2 發布 Beta 版本？

01-09

http://angularjs.blogspot.jp/2015/12/angular-2-beta.html?m=1

截至答題時的問題是：

如何評價beta版的Angular2？

首先我確實覺得問題問的不好，我覺得應該改為『如何評價 Angular 2 發布 Beta 版本？』。

前者的話語義上像是問 Angular 2.0 beta0 相對於 Angular 2.0 alpha 55 有什麼改進（這個 Change Log 裡面還真沒寫，在 MileStone 里後幾個 alpha 都算到了 beta 里。。所以我也不知道。。），後者問的是 Angular 2.0 這個框架進入到 Beta 版本的重大歷史意義。。

---（雖然不是 Markdown 並不會變成實線）

至於框架細節上，相關的文檔和教程已經不少了，所以這裡主要說一些觀念上的理解。。

0. 作為前端框架， Angular 2.0 太重？

是，也不是。

這個問題在 1.x 的時候就經常被討論，也嘗嘗被一些人作為 Angular 的黑點。實際上，Angular 的一個基本理念就是提供一個大一統的前端解決方案，涵蓋 MVC or MVVM or MVW 的每一個層面的每一個功能點，當然，並不是說每個環節 Angular 自己都是做的最好的，但用戶基本都具有選擇權，可以選擇別的庫或框架來替代（ui-router、restangular 等）。為此，本身 Angular 的庫文件也是模塊化的（不需要的可以不引入）。

而可能其他一些框架，更專註於某個特定層面（比如 View 或者 ViewModel），當需要在別的層面進行擴展時，就需要在相應的生態系統中尋找別的解決方案，為此可以保證自己的足夠輕量。

就策略上來說，兩種選擇本身都無可厚非，但可能到具體實踐中，Angular 中的很大一部分都是不會用到的（但是依然出現在文檔中），所以導致了一種 Angular 十分臃腫不堪的觀念。

1. Angular 2.0 完全重寫了 Angular，相對於 1.x 的學習曲線太陡？

是，也不是。（好像快成廢話了）

Angular 1.x 有一個奇怪的現象，就是一坨人覺得它易於上手，另一坨人覺得它過於複雜。其實確實說的都沒有錯，因為 1.x 上手需要用到的部分很少，知道有個 Controller 和 Scope 就已經可以做出很多應用了，所以用戶水平嚴重分化（從能用 ngRepeat 和能造 ngRepeat 不等）。對於非科班出身的童鞋，要面對 compile、link、inject 等等名詞可能有些力不從心。

因為 Angular 2.0 里去掉了 Scope 和 Controller，所以，Angular 2.0 真的推倒了 Angular 1.x 中的一切嗎？我們來看一個簡單的例子。

Angular 1.x 中有一個 Controller 的概念，Controller 雖然叫 Controller，但遠沒有後端框架中的 Controller 那麼複雜的作用，Angular 1.x 中的 Controller，說得不好聽一下，就僅僅是一個初始化器（Initializer），進行相關的數據綁定（包括欄位和方法）而已，一般的初學者用法如下：

// Angular 1.x with $scope in ES5
myApp.controller("myController", ["$scope", "itemService", function($scope, itemService) {
$scope.currentItem = itemService.current();
$scope.items = itemService.all();
$scope.add = function(item) {
itemService.add(item);
};
}]);

可以看到，上面的代碼中，Controller 乾的事情僅僅就是把相應的數據或者方法綁定到 ViewModel 中。隨著 Angular 1.2 中 Controller As 語法的到來，就不再需要 $scope 了：

// Angular 1.x with "controller as" in ES5
myApp.controller("myController", ["itemService", function(itemService) {
this.currentItem = itemService.current();
this.items = itemService.all();
this.add = function(item) {
itemService.add(item);
};
}]);

這樣，就可以拋棄 $scope 了（其實事件傳遞還是有可能用到），很多人不知道 Angular 1.x 早就不需要（甚至可以說不應該）用 $scope，所以覺得 Angular 2.0 沒有 $scope 還能算 Angular 嗎？

接著（不過這裡 Controller 看似多了一個職能，作為閉包），看到 this 之後，我們不妨思考一下，這些屬性到底是對象獨有的還是類（嚴格地說JavaScript中叫原型）共有的呢？通常欄位都是前者、方法都是後者，即只要是這個 Controller，都要有這些方法。這樣，我們就可以考慮，把不變性的內容（比如基本上所有的方法）作為原型的屬性而非對象的屬性：

// Angular 1.x with "controller as" in ES5
myApp.controller("myController", ["itemService", ItemController]);

function ItemController(itemService) {
this.currentItem = itemService.current();
this.items = itemService.all();
}

ItemController.protoype.add = function(item) {
itemService.add(item);
};

這樣就避免了把一坨方法綁定也擠到 Controller 里，也可以更清晰的看出 Controller 的初始化作用。（this 會順著原型鏈查找的，但是可能很多用 Angular 的人並沒有清晰的看到 Angular 仍然是普通的 JavaScript。）然後，隨著 ES6 的流行，我們可以很輕鬆的轉換成 ES6 的版本：

// Angular 1.x with "controller as" in ES6
myApp.controller("myController", ["itemService", ItemController]);

class ItemController {
constructor(itemService) {
this.itemService = itemService;
this.currentItem = itemService.current();
this.items = itemService.all();
}
add(item) {
this.itemService.add(item);
}
}

所以，因為 Controller 的作用就只是初始化，在有了類（class）的情況下，就完全可以被同化到 class 的 constructor 裡面了。如果開發人員喜歡靜態類型的話，還可以使用 TypeScript，也就相當於在 ES6 的基礎上增加了一個靜態的類型系統：

// Angular 1.x with "controller as" in TypeScript
myApp.controller("myController", ["itemService", ItemController]);

class ItemController {
private currentItem: Item;
private items: Item[];
constructor(private itemService: ItemService) {
this.currentItem = itemService.current();
this.items = itemService.all();
}
add(item: Item): void {
this.itemService.add(item);
}
}

其中，用到了 TypeScript 的一個語法糖，即在構造函數的參數名前加上可訪問性修飾符（private、public）可以直接添加為實例的屬性。

如果我們有組件化的需要，可以把使用 Controller 的地方都寫成 Directive，避免 ngController 的濫用：

// Angular 1.x with "directive" in TypeScript
myApp.directive("some-selector", () =&> ({
restrict: "E",
controller: ["itemService", ItemController]
}));

class ItemController {
private currentItem: Item;
private items: Item[];
constructor(private itemService: ItemService) {
this.currentItem = itemService.current();
this.items = itemService.all();
}
add(item: Item): void {
this.itemService.add(item);
}
}

特別提醒，到這裡都還是普普通通的 Angular 1.x 哦。（很明顯的可以看出，Controller 就是 Directive 的一個方法。）

最後，我們再看看 Angular 2 中的寫法：

// Angular 2 with "component" in TypeScript
@Component({
selector: "some-selector"
})
class ItemController {
private currentItem: Item;
private items: Item[];
constructor(private itemService: ItemService) {
this.currentItem = itemService.current();
this.items = itemService.all();
}
add(item: Item): void {
this.itemService.add(item);
}
}

基本上唯一的區別就是，由於 TypeScript 提供了 Metadata 支持，Angular 2 可以直接按類型注入（當然也依然可以使用按名注入，如果有特殊需求的話），不需要再手動鍵入依賴名稱了。（@符號是 ES7 的 Decorator，並不是 Angular 或 TypeScript 的私有語法。）

另外，由於本身的組件化要求，Angular 2.0 的 Component 自身就可以構成一個連通樹，用來相互通信，所以也不需要 1.x 中藉助 $scope 來進行通信了，所以 Scope 這個概念被廢棄了。Controller 作為一個進行初始化的方法，直接被類的構造函數取代，不再需要一個專門具名函數了，所以 Controller 這個概念也被廢棄了。

所以，在 Angular 2.0 里，真的因為沒有 Scope 沒有 Controller 就是全部推倒重寫了嗎？並沒有。Angular 2.0 仍然大量的繼承了 1.x 的思想（好的那一部分），或者說，Angular 2.0 是 Angular 1.x 最佳實踐的延伸，學習成本基本都在 Angular 1.x 的最佳實踐上，但是如果本身在 Angular 1.x 就只會基本的 ngRepeat 使用的話，那是完全沒有學會 Angular 1.x，而並不是在學會了 Angular 1.x 的情況下學不會 Angular 2.0。

（當然，側面說明了 Angular 1.x 的學習曲線真心陡。。）

2. Angular 2.0 的組件化過於繁瑣，不適用於簡單項目？

是，也不是。（。。。）

這裡說的組件化是指實現上的組件化（即必須要聲明 Component），而不是觀念上的組件化。或者說，僅僅是滿足寫成 Tree of Component 可能根本不需要任何的組件化思想。

關鍵在於，這裡的組件化，並沒有任何的粒度要求，自然也就不存在複雜度的要求，你可以整個 App 一個組件，也可以每個 Element 一個組件。如果只是在原有的 ngApp 一級組件、ngView 一級組件（滿足路由的基本需要）的話，真的能說得上繁瑣么？（當然這樣會被罵根本就不是組件化）工程上來說，完全可以等到了真正需要復用的時候，再來進行進一步的抽象。。

3. 把 HTML 和 CSS 寫在 JavaScript 裡面真的很噁心么？

不知道。

這裡澄清一下，Angular 從 1.x 到 2.0 一直提供了 template 和 templateUrl 兩種方式，即喜歡 inline 的可以寫成 inline，喜歡外置的可以寫成鏈接。至於政治正確性？Angular 1.x 一直是以 templateUrl 為導向，2.0 的話目前首頁是 templateUrl ，文檔多是 template。

鑒於現在的文檔和臨時文檔也差不多（很長時間內甚至連臨時文檔都沒有），所以不談論最終結果，只簡單提一下為什麼 2.0 的文檔有用 template 的可能性。第一點是 ES2015（ES6）提供了模板字元串的語法，可以用反引號 `` 直接創建多行文本（實際上還能內插變數）；另一點是在真正組件化的情況下，一個 Component 的 View 和 Style 都不會很多（理論上應該不會超過兩隻手），所以視覺上對可讀性影響不大（情懷上就不知道了。）

另外，Angular 2.0 通過 ViewEncapsulation 可以配置 Style 的污染程度，可以選擇不受全局 CSS 影響也不污染全局，受全局 CSS 影響但不影響全局，受全局 CSS 影響也會污染全局。

歸根到底，Angular 一直提供給用戶足夠的選擇權，包括 2.0 可以自由使用 TypeScript、Dart 或 ES5 開發等等，我個人認為 Angular 這裡已經做的足夠好了，當然永遠避免不了程序員之間的戰爭這也是沒辦法的，但把 Angular 支持另一派別的寫法當成黑點來看待我覺得有點矯枉過正了。。

4. Angular 2.0 來的實在太慢了么？

是的。

從結果上來說，確實是這樣。而且截至目前也僅僅是 Beta 版本，真正要能被大規模應用到實際產品中可能需要在正式版發布的若干次更新以後。對於已經使用了別的框架的用戶來說，目前看來並沒有什麼充足的理由轉投 Angular 2.0；對於還在堅守 Angular 1.x 的用戶，也多半並不是因為對 Angular 有特殊的情懷，只是因為技術或其他原因而不願改變現狀。Angular 2.0 要達到 1.x 那樣的市場份額的可能性微乎其微。

5. 占坑。

Angular 2是一個重量級前端框架，明顯比Vue重，作為全業務解決方案來說，大致和React整合了一堆東西之後在一個數量級。

這麼重的一個東西給誰用呢？兩種場景：基於Web的企業應用，混合應用（包括桌面端和移動端）。

我們可以發現，什麼樣的人非常歡迎Angular這麼個體系，那就是有Java背景的Web開發者，這部分人大部分在做的就是各種管控系統，包括CRM、ERP軟體，雲平台之類。而且，需要在這個領域中算是比較有前端意識的人，才寧可傾向於Angular而不是ExtJS。

儘管在整個前端開發圈中，大家並不是很歡迎Angular，而且很多人認為它的1.x版本已經衰落，但我跟 @小豬有個觀點是一致的，那就是：「在企業開發領域，ng1的應用才方興未艾」，也就是說，它在這個領域其實還是上升階段。

為什麼呢？還是因為缺少對手。我們可以對比一下幾個競爭對手，看看為什麼這個領域的人更願意選擇Angular。

  • Vue，從前端的角度看，Vue有一萬個好，Angular有一萬種令人不滿的地方，但企業領域的人偏愛集成解決方案，哪怕這個方案的語法是粗陋的，配置是繁瑣的，連Java都用了，還怕這些？更關鍵的是ng1非常貼合Java開發人員的習慣，所以只要搞過Spring這類東西的，經過簡單培訓，寫配置頁面極其熟練。
  • React，與Vue相比，React還強制組件化理念，但是絕大部分管控系統其實是不需要組件化的，在這類系統中，模板比組件更便捷。
  • ExtJS，這個會在企業領域有不少市場，但隨著用戶對UI多樣化的需求增加，不少人會逐步選擇棄用它，而且它的開發效率並不算高，唯一優勢是組件豐富而且適合企業領域。

所以，綜合來看，如果你有一個這個領域的系統要開發新版本，仍然沒有太好的選擇。

再看看Angular 2，一年前，我曾經回答過相關的一些問題，在這篇的評論中，有過對於版本發布時間的預測：Angular 2.0與1.3版本相比，有哪些方面的改進呢？ - 徐飛的回答，現在看來，大致是準確的，為什麼我當時覺得要這麼久時間呢，有這幾方面的考慮：

  • 太受關注了，大家對1.x的吐槽那麼多，開發團隊肯定亞歷山大，所以很多他們的想法都會不自覺被這些言論引導，而且整個過程一直公開，在很多點上，會有爭議，其實不一定非要改那麼多的，可是你擋不住每個人都把他所擁有的認知往上加。做框架的時候，核心團隊只能有2-3人，不然不可控因素太多了。《商君書》教導我們：民不可與慮始，而可與樂成。從決定一個框架流行度的因素來說，事後的宣傳和社區運營要比設計過程重要得多，只要不出致命問題，都可以認為是沒有問題，是feature而非issue。

  • 想要做的事情太多了。比如說，可選渲染引擎，可選模塊系統，考慮支持同構模式，考慮支持Native渲染，而且一會要考慮集成Rx，一會要考慮是否引入Imuutable，隨時受到社區流行元素的影響，總是企圖一勞永逸，這是不可能的事，沒有哪個前端框架能夠一次搞出拉鉤上吊一百年不許變的模式，能選用Angular這樣框架人，基本都會用默認配置，不會真的這麼geek到自己替換模塊的，要能這麼干，他早就用Vue去了。

所以，我覺得做到現在，Angular團隊的人自己也迷惘了，早期Rob Eisenberg離開創立了Aurelia框架，近期這個庫：angular/watScript · GitHub，都反映出內部的人思想上的鬥爭與困惑：我們到底想要什麼樣的東西？從過程來看，這是必然的事情，可以預見到現在這種局面。

其實，以現在Angular 2 Beta版所擁有的東西，已經非常超前了，但這個超前有沒有用呢？說實話，不會很大。兩個方面看：

  • 能不能吸引到新用戶？能嗎，絕對不會有想像的那麼多，為什麼呢，因為一個成熟的開發人員，他考慮技術選型，並不是你很先進我就會用，而是要看你是否適合我的業務形態，對我的人員是否增加太多學習成本，能否帶來明顯的好處。至少現在沒那麼明顯，等HTTP2普及度更高之後，或許會好些。

  • 能不能拉住老用戶？能拉住一些，但失去的可能更多些，失去的原因主要還是一年前自己的那些豪言壯語。其實ng1.x真的那麼不堪嗎？不見得，只要把module機制這樣的問題修改一下，仍然還是個很不錯的框架，而且1.4和1.5版本加入的不少東西，也是非常有優勢的，可惜很多見到風就是雨的人，會被那些言論嚇跑了，不會持續關注。

小豬的答案中提到另外一點：

面向component編程是解決界面複雜性的好手段，但是，同樣會帶來代碼複雜度上升的代價，從我的實踐來看（不是angualar），這個平衡很難把握，而且有些懶惰的開發人員也不是很樂意在開發中仔細的拆分組件。

深表同意，我個人前一段時間寫的《Web應用組件化的權衡》：Web應用組件化的權衡 · Issue #22 · xufei/blog · GitHub就是闡述這方面觀點的。

另外，對於開發語言的變更，很多人覺得是個問題，但我覺得對於企業開發者來說，這個還屬於可接受範圍。

莫大藝術家 的回答中，把ng2和ng1的升級比作as3和as2，非常好的比喻，贊。

好了，說點總結吧：不管怎樣，終於發布了，是好事。新版本更加強大優雅，但學習成本也更高了，這裡面很多理念，對新時代的前端來說確實是必備技能（ES 2016，TS，Rx等等），從這個角度看也可以理解。能不能達到ng1曾經擁有過的輝煌，不得而知，80%的可能性是沒有。

我要吐槽的比較重要的一點是：

我認為如果組件要依賴其他組件，其import過程應當放在html模板中，而不是放在ts代碼里。MVVM三層，明顯越上層越屬於配置層，組件依賴數據配置信息，應當放在模板中更合適，對比一下這篇提出的跟Aurelia的對比：

http://blog.durandal.io/2015/05/20/porting-an-angular-2-0-app-to-aurelia/

另外，個人對Angular 2這次的Beta版有個猜測，官方其實還沒有這麼早把它推出的準備，因為官方從1.3版本之後，又陸續創建了1.4和1.5兩個版本，當初說好1.3就終止的呢？可見自己並沒有信心，這次推出ng2的Beta版，很可能是受到Aurelia前一陣發布Beta版的刺激所致……

附帶說句話，最近這些五花八門的框架，近期看，沒有誰能夠取代誰，有很多人拿出自己的作品來證明所用的東西好，其他框架不行，其實。。。是因為不管用哪個東西，都能做出你這樣的作品。尤其是管控類的系統，還是那句話：輕量級的管控系統，至少有一百種做法。

其實從Angular大改版到Angular2，我就預感到了，真正的Web 和 Mobile的融合即將到來。

周末我特別無聊的，翻騰出了自己三年前的代碼重新看了一遍，當時自己實現了很多好用的方法，比如

setTimeout(function(){xxx},1000);

改寫成了

function(){}.delay(1000);

delay的實現，完全依賴了回調函數的處理。

後來經歷了jQuery的改版，其中引入了Deffered（Promise）實現

始終感覺到，這只是在目前簡陋的開發條件下（javascript）的一種擴展實現，代表不來前端的未來，非同步處理過程，對前端來講，是複雜度的根源

後來前端框架雨後春筍，從Backbone到近兩年的Angular出現，逐漸的，MVC的概念已經逐步的擴展到了MVVM,又經歷了Angular團隊對Angular徹底推翻進行Angular2開發，明顯的感覺到，其實前端這個行業已經不再是以前意義的前端行業了

那麼可以簡單的去寫，2015年，是一個分水嶺，15年之前，是前端開發，搞js，html的，15年之後，是真正的人機交互開發，是搞組件，搞控制項，搞工程化眾包開發的。

不好理解？

那麼可以理解一個真正的歷史

AS2和AS3 是一個完全基本OOP的標準化面向對象語言，最重要的就是as3不是as2的簡單升級，而完全是兩種思想的語言，不兼容。

AS2，都是在控制Flash中的元件，Flash中的素材，但是到了AS3，基本上都是層層繼承，面向介面去定義所有的對象，AS2開發，基本以設計居多，但是AS3開發人員中，很大一部分，都是類JAVA開發轉居多。

返回說前端，15年之前，大家應該還是在運用選擇器，選擇DOM，進行DOM的狀態切換組合，事件監聽等等，但是未來的開發，應該都是基於組件體系的一個控制流，譬如控制項與數據流之間的通信，未必會全部基於Http/s協議，也有WS，本地CacheStore存取，即便給予Http，那麼也有Web Workers的Thread並發概念，數據處理完全可以從頁面渲染流程中脫離，

那麼再說一下Rxjs的概念，這基本上都是Observable Sequence的概念，相互訂閱通知，根據狀態的切換來進行不同的處理方式，而且，這種組件組件之間或者組件數據之間的通信，很容易寫成隱形的封裝。

Angular1.x基本上也是類Flex的給予Observable的設計理念，但是，目前的ViewModel之間的狀態切換，還是依賴於EventListener CallbackPromise實現的通信協議，就是Dirty Check邏輯，當然，這樣能夠為你的模型使用純老式的JavaScript對象。

Angular2，其實真正的改變，並非框架版本號從1.x到了2.x，也並非切換到Typescript，也並非號稱的組件化模塊化響應，也不是裝飾化聲明（Meta？

而是理念的改變。

這對90%的前端開發，基本上都是很痛苦的折磨。

尤其是，這種開發思路，其實可以無限制的放大到Application For Desktop上。

當打開一個人機交互頁面，思考一下操作流程：

當我點某個按鈕的時候，打開某個窗口，展示什麼內容，這一切怎麼轉化成程序描述語言？

難道還是 Query.on event do function ?

文章來自我的博客

前端的未來，寫在Angular和React火熱之際

更新：

如何工程化開發大型angular2項目（上篇續）（分享自知乎網）https://zhuanlan.zhihu.com/p/24545021

淺談一下從3月份到現在用angular2的體驗。alpha版到rc.7，之間變動之大。router系統重構好幾版，component組件編寫語法也是變了好幾次。上頭追新，作死應用到生產環境，應用越做越大，打包出來JS都快2、3M。導致客戶普遍抱怨首屏載入慢。還好後來在Nginx伺服器上做了優化，還有angular提供了預編譯技術，先渲染HTML。速度提升60%。

這裡也不是抱怨angular小組技術變動大，畢竟還是研發階段。我想提一點是，追求新技術是值得鼓勵的，但是不要把還在研發的技術應用在主線產品中，而是用在一些內部系統中。不然真是血的教訓。

當然要說說，angular這次變革式創新出了2代。優勢有

1.學習成本降低，因為有中文版文檔www. angular.cn,在也不用聽新同學抱怨英文看不懂。基本看幾天就能上手。會angular2,看vue基本無壓力，反過來也行得通。

2.技術實現成本降低，用angular1實現組件共用，用2輕鬆實現。現在項目里已經有很多通用組件了。

3.react，vue的redux，angular2也有，ngrx技術。

4.對於選擇恐懼症的盆友，angular2真是一站式服務。

5.聽說react可以開發native app，不好意思angular2和nativescript也可以開發原生app。 忘了說一句，angular2還可以開發react native。(自行上GitHub搜索angular2 react native).

6.最六的是支持Rx.JS。

7.人生苦短，快用angular2吧。

PS：哪有蘿蔔坑，準備挪坑，私聊

  1. 允許js代碼混合html的寫法有些噁心。。。

  2. 面向component編程是解決界面複雜性的好手段，但是，同樣會帶來代碼複雜度上升的代價，從我的實踐來看（不是angualar），這個平衡很難把握，而且有些懶惰的開發人員也不是很樂意在開發中仔細的拆分組件。

  3. angular1 很可惜，angular2拋棄了一代的mvc結構完全重起一套，我覺得這種情況下還莫不如另外起一個名字，就叫polymer不好么。。。ng2對前端來說是一個可以快速上手的框架，ng1對很多前端來說覺得繁瑣到噁心，然而，在企業開發領域，ng1的應用才方興未艾，而ng2的模式在企業領域是不可能得到應用的，因此，可以預見，會有社區接手ng1的長期維護，主要面向企業應用開發領域，而且實際上ng1是唯一一個企業應用開發領域的開發人員可以快速上手掌握的前端框架。

從 Angular "2.0.0-alpha.27" 版本開始學習，閱讀，開發到現在的"angualr2-beta-0"， beta給我的感覺就是終於要穩定了。

前端團隊從年初就開始考慮是不是要入坑 Angular2 做一個編輯器。自從決定使用Angular 2 alpha27 開始，每寫一行代碼都在打破我對 Angular 的認識。 我認為Angular2 之所以強大，有很大一部分 Typescript 的功勞。 Typescript 的可讀性很高。 多次升級都不是根據 changlog 的介紹， 而是點進 commit 裡面看 Angular team 改動的代碼。 當然 Angular1 你也能這麼做。 只是很多時候需要猜輸入是什麼格式罷了。 但是你會發現，當 Angular2 team 想拆了東牆補西牆修 bug 的時候，Typscript 會阻止他，或者說就是升級不能。 這也許就是最大的好處。

Angular2 beta發布之前，在一周內一口氣發布了5個版本，breaking change 非常多。 對於我們影響最多的主要還是在改 typing 的問題上。 之前 import （載入） 大多數 module （模塊） 都是基於路徑 "angular2/angular2"，現在是完全不能用了。因為 "angular2/ angular2.d.ts" 直接被砍了。 現在要 import 任何一個 module 都必須選擇他的 "barrels"（桶？） 如 "angular2/core"。這對我們程序猿們產生了很大的問題。 鬼知道他哪個模塊是從哪來的。 這其實是我們程序猿本身的問題。 我們對自己使用的框架並沒有深入的了解。 基於 Angular1 開發網站時只是看看教程，看看語法糖，最多看看文檔。 並不管每一個 function（功能）後面的代碼到底是怎樣連接或者工作的。雖然我們也會看什麼是 MVVM 什麼是 RESTFUL，但是用了 Angular1 這麼久了，讓我們改改裡面的代碼，卻完全不會去想。如果遇上需要的功能，就在 controller directive 或者 service 裡面去實現。而現在則會去看 Angular2 的源碼，明白為什麼不能用，然後再做對策。這是一種理念的改變。 我們覺得現在更願意去寫一個可以接入框架的功能，而不是在某一個特定頁面位置寫特殊功能。在這一點上，Angular2 和 Typescript 帶給我們團隊的是一種可以更好學習和工作的框架，而不僅僅是拿來使用的 Angular1。

回來接著說最新發布的 Angular2-beta-0 的坑。我們現在有兩個坑並沒有辦法解決。一個是Angular2 自動載入 node.d.ts 的問題。前端是不用node.d.ts的，那個後端的 typing，但是在 "angular2/core.d.ts" 中 import（載入） 了 "globals-es6.d.ts"。 之後又 "reference" （引用）了 "node.d.ts"。另一個坑是angular2-beta-0 自己還有若干個文件引用 angular2/node-module 下的 zone.js。 這個也是無解的，我也不能說改它的路徑。原因是希望能保證 npm 包的完整，而且 Angular2 team 自己也會在下一個版本？修復這個問題。本來在alpha版時 Angular2 是自帶 dependency 的。會看到他的node-module里有 "zone.js" 和 『reflect-metadata"。到了 beta 肯定想刪掉，但是又沒刪完全。（這哪有那麼好刪的）

－－－－－－－－－－－－－－－－－－－－－

對於一些理論和語法的改動。 至今為止遇到最多的就是 『＝』 two way bining（雙向綁定）沒有了。 每一個輸入都有來源，輸出都有去處。我們可以通過追蹤輸入輸出的事件來進行很多頁面或者數據的改動。 這些在 Angular1 中我們必須使用消耗更高的 "$watch" 功能。反之，"$watch" 的功能簡易程度要大於 Angular2 中的輸入輸出。 這使我們覺得 Angular2 更適合開發更大型的網站，並保持邏輯性和運行效率。 並不是一味的給予程序猿語法糖。

－－－－－－－－－－－－－－－－－－－－－

Angular2 仍然是beta版本，並不適用生產做業。 我們團隊選擇用 Angular2 雖然是三四而後行了，但現在想想也沒有辦法說當時選擇react flux是不是更好一些， 並且現在感覺沒有什麼退路。 今年沒有完成編輯器的發布也是給公司帶來了很大的壓力，所以說並不是完美的戰略計劃。如果只看這個框架，Angular2 從 Angular1 吸收了大量的經驗和錯誤，朝著更為清晰的方向發展。作為程序猿只能希望它越做越好。

Beta means we"re now confident that most developers can be successful building large applications using Angular 2.

其實 ExtJS 挺好的。

推薦閱讀：

※如何看2015年1月Peter-Paul Koch對Angular的看法？
※angular中控制器之間的傳值該怎麼實現?
※angular中，controller、directive和factory分別該在何時使用？
※AngularJS按需動態載入template和controller?
※angularjs中不同頁面controller中數據傳遞的問題？

TAG:AngularJS | Angular? |