① 《AngularJS權威教程》pdf下載在線閱讀，求百度網盤雲資源
《AngularJS權威教程》（[美] Ari Lerner）電子書網盤下載免費在線閱讀
資源鏈接：
鏈接：https://pan..com/s/1xdVsoDN5VG2vlOuWSkkXGQ
書名：AngularJS權威教程
作者：[美] Ari Lerner
譯者：趙望野
豆瓣評分：7.3
出版社：人民郵電出版社
出版年份：2014-8
頁數：476
內容簡介：本書是資深全棧工程師的代表性著作，由擁有豐富經驗的國內AngularJS技術專家執筆翻譯，通俗易懂、全面深入，是學習AngularJS不可錯過的經典之作。無論是出於工作需要，還是好奇心的驅使，只要你想徹底理解AngularJS，本書都會讓你感到滿意。
本書將涵蓋AngularJS的如下概念。
雙向數據綁定
依賴注入
作用域
控制器
路由
客戶端模板
服務
通過XHR實現動態內容
測試
過濾器
定製表單驗證
深度測試
定製指令
專業工具
對IE的支持
作者簡介：作者簡介：
Ari Lerner
是一位全棧工程師，擁有多年AngularJS經驗，自辦並運營AngularJS電子報ng-newsletter.com，在著名矽谷工程師培訓學校Hack Reactor擔任AngularJS講師。他的工作涉及軟體開發的各個層次，包括基礎設施開發、前端應用開發和性能優化。他目前住在舊金山一個陽光明媚的地方，還是FullStack.io創始人。
譯者簡介：
趙望野
前端工程師，前端基礎技術組leader，曾經負責豌豆莢2.0的前端架構設計和主要開發工作，目前負責Front-end Technical Infrastructure的建設，在工作中有豐富的AngularJS使用經驗。新浪微博@趙望野。
徐飛
2005年至今一直從事企業應用前端架構，對富網際網路應用有較深刻的認識，致力於前端的高效開發，研究過Backbone和AngularJS的源碼，翻譯過講解AngularJS基本原理的文章，對臟數據檢測和基於存取器兩種監聽方式的差異有深刻認識。
何鵬飛
網名basecss，目前就職於騰訊CDC，任前端工程師。喜歡閱讀，喜歡前端技術，崇尚開源。工作之餘翻譯過Grunt和Lesscss相關文檔，同時也是Lesscss中文社區貢獻者。
② 如何評價淘寶 UED 的 Midway Framework 前後端分離
【賀師俊的回答(17票)】:
瀉葯。
1. 這系列文章寫得很好。
【注意，熟悉我的同志應該知道，我極少給出「很好」的評價。】
2. 這系列文章以及其背後的實踐重新樹立了淘寶系前端工程水準的領先地位。
【在此之前的一段時間內，至少從外部來看，淘寶已經落後於狼系和企鵝系了。】
3. 這系列文章及其背後的實踐也證明了nodejs對於前端來說不僅在工具鏈而且在架構層面的意義。
【注意，這系列文章中的思路其實並不新鮮，但是在淘寶這樣規模而且業已非常成熟的產品中實施這樣的轉變，我認為是具有標志意義的。】
4. 具體細節上仍有許多改善空間，如此系列的第4篇《前後端分離的思考與實踐（四）》在防禦XSS時還是存在一些傳統問題。這方面在參加杭JS的時候，我跟淘寶的herman同學有過溝通，具體就不在本問題展開了。因為這是局部問題，對整體架構影響不大。
5. 注意，以上評價的都是架構，或者說是思路。實施效果是不是好，我相信他們自己的說法。但Midway框架本身因為沒有看到具體文檔和代碼，而且其開發的目的首要是滿足淘寶的需求，因此其本身或其具體組件是否在普遍意義上適用和優秀，無法作出判斷。
【徐飛的回答(19票)】:
早上看到賀老出馬，也忍不住寫了一篇來談一下蘇寧這樣的公司對這方面的考慮。
近兩年來，我一直在思考如何改進前端體系的開發模式，這裡面最基礎的一點就是前後端的分離。談到前後端分離，也有一個誤區，認為僅僅是以瀏覽器作分界，把這兩部分的代碼分離出來。但其實是，做這件事情的本意，是要解決開發模式的問題，也就是要分離前後端開發人員的職責。
針對不同類型的Web產品，這個分離方式是有所不同的。對於Web應用，因為它跟服務端的交互基本就是AJAX或者WebSocket介面，所以這個分離是天然的，整個前端基本都是靜態HTML模板，JavaScript模塊，以及CSS和相關靜態資源，但是對於網購產品這樣的形態，它的做法就不一樣。
## 展示佔主要部分的產品
網購產品的展示需求很重要，圖片等資源載入非常多，但相對的操作卻很少，基本只有搜索商品，加購物車，結算這樣的環節。傳統這樣的產品，多半是這么個工作流程：
交互出高保真圖，前端去切圖，生成靜態HTML加展示效果，然後，注意，他不是自己接著往下做，而是交給另外一群開發人員，把它轉換成服務端模板，比如freemarker或者velocity之類，或者是smarty，為什麼要這么做呢？因為這類產品講究一個首屏優化，是首屏而不是首頁，這就意味著對於首屏來說，經過的環節應當盡可能少，比如說，就不能先載入客戶端模板，再AJAX一個數據，然後去渲染一下。這么做的性能肯定是不如服務端把HTML生成好，然後一次請求載入的。
這個過程肯定是有一些問題的，比如說，如果開發人員B在套模板的過程中，發現原先的靜態HTML部分有問題，應該怎麼辦？大家知道，一個對HTML和CSS都很熟悉，同時又可以寫業務邏輯的前端開發人員是很稀缺的，所以，多數情況下，這兩邊的技能是不同的，如果是簡單的頁面問題，這個開發人員可能自己也就解決了，如果他解決不了，怎麼辦？
如果B自己不改，把他已經搞成服務端模板的代碼返回給前端人員A，A也沒法下手，因為已經是服務端模板，A手裡沒有環境，改了之後不知道對不對，不能預覽。那麼，B把問題告訴A，A修改他的原始版本，然後再拿給B又怎樣呢？這時候B又麻煩了，他要對比兩次修改的部分，把自己前一陣的修改合並進去。
所以，不管怎麼搞，這裡面都很折騰。
Midway這個產品，他想要解決什麼問題呢？既然說前端人員沒法預覽模板的原因是，後端在使用服務端模板，那麼，我能不能找一種兩邊都可用的模板，你能在服務端渲染，我也能在客戶端預覽？服務端跟瀏覽器端同時都能運行的語言是什麼？只有JavaScript。
所以，大家就往nodejs裡面去發掘了，一個普通的JavaScript模板庫，它在瀏覽器端也可以渲染，在nodejs端也可以輸出成HTML，這時候，那些原來負責整合模板和邏輯的人員改用nodejs，是不是就解決這問題了？
想像一下這個場景多麼美好：前端來決定某個模板是服務端渲染還是客戶端渲染，當首屏的時候，就在nodejs裡面生成HTML，不是首屏的時候，就AJAX過來在瀏覽器端渲染展示。
從技術方案上看，這么做很好了，工程上又帶來另外一些問題，那就是對熟練JavaScript開發人員的需求量大增。對阿里這樣的公司來說，前端有大幾百人，別的公司只能仰望，所以他當然可以放手一搞，但對我們蘇寧這樣，前端人數不大的，就麻煩了。如果我們也引入這樣的方案，就面臨把很大一部分Java開發人員轉化成JavaScript開發人員這么一個問題，這個事情短期內肯定是無法解決的，所以反過來會增加前端這邊的壓力。所以暫時還用不了阿里這樣的方案，只能努力先提高人員水平再看情況。
服務端引入nodejs還有別的優勢，比如說請求合並等等，這個也可以用其他方式變通解決，比如加一個專門的跟現有後端同構的Web伺服器，在那邊干這些事。
## 展示和業務邏輯較均衡的產品
對於另外一些場景，也有類似的問題，比如支付產品，展示相對沒那麼重，但是又算不上Web應用，它面臨另外一種情況的前後端分離。這種場景下，前端的出靜態HTML和DOM操作類的JavaScript，業務開發人員負責寫後端，還有另外一部分業務邏輯的JS。
這里的問題是什麼呢？是jQuery式代碼造成的協作問題。比如說：
$(".okBtn").click(function() { $.ajax(url, data) .success(function(result) { $("someArea").html(_.template("tpl", result)); });});
因為前端人員的稀缺，所以他不可能幫你把業務邏輯寫出來，所以說，這裡面$.ajax往裡的部分，要業務人員自己寫。然後，數據得到之後，又要去處理界面部分。
很多場景下，處理界面遠不是這么搞個模板放上去就完事的，所以業務開發人員感到很煩悶，為了這么一點小問題，反復去找前端的人來搞，很麻煩，自己搞又特別花時間，所以都很苦悶。
這同樣是一種前後端的分離，只是這個分界線不在瀏覽器，而在於：是否寫業務邏輯。對付這種場景，解決辦法就是加強JavaScript代碼的規劃。現在流行那麼多在前端做MV*的框架，不考慮Angular這類太重量級的，來看看Backbone這樣的，它到底解決了什麼問題？
很多人說，Backbone雖然小，但根本不解決問題。這句話有一定道理，但前提條件是你自己的JavaScript代碼分層已經做得很好了。如果做得不好，它就可以協助你解決分層的問題。
剛才那段代碼，它的問題在哪裡呢，在於職責不清晰。一個函數只能做一件事，這是共識，但由於回調等方式，所以不經意就破壞了函數的單一性、完整性。我們試試來拆開它。
對於一個後端開發人員來說，他為什麼常常害怕寫前端代碼？是因為JavaScript語言嗎？其實不是，我們用來寫業務邏輯的時候，只會使用JavaScript一個很小的子集，對於這個子集來說，它並不存在多大的學習困難，最麻煩的地方在於DOM、BOM等東西，對於一個後端開發人員來說，如果要求他在掌握服務端代碼編寫的同時，還要去學這些，那真是有些不容易，所以，我們來給他省點事。
現在我們的出發點是，把這段代碼拆給兩個不同的人寫，一個人操作DOM，另外一個人只寫邏輯，絕對不操作DOM。前面這個代碼拆給前端維護，後面這個拆給業務開發人員。
最老圡的方式：
a.js
$(".okBtn").click(function() { b1(data);});function a1(result) { $("someArea").html(_.template("tpl", result));}
b.js
function b1(data) { $.ajax(url, data) .success(a1);}
現在大家是不是相安無事了？
如果這么做的話，AB雙方要做很多約定，也就是說，這個過程仍然是一個螺旋鏈。比如說，A先寫點擊事件的綁定，然後想起來這里要調用一個請求，就去找B寫b1方法。B在寫b1的時候，又想到他要調用一個界面展示方法a1，然後又來找A寫，來回也挺折騰。
況且，有這么一天，A在另外一個地方也想調用b1了，但是由於b1的回調已經寫死了，比較蠢的辦法就是在a1裡面再判斷，這是什麼東西點擊造成的，然後分別調用不同的回調。如果情況復雜，那這個代碼寫出來真是沒法看。
如下：
a.js
var type = 0;$(".okBtn").click(function() { type = 1; b1(data);});$(".okBtn1").click(function() { type = 2; b1(data);});function a1(result) { if (type1) { $("someArea").html(_.template("tpl", result)); } else if (type2) { // ... } type = 0;}
b.js
function b1(data) { $.ajax(url, data) .success(a1);}
稍微好一些的辦法是，在b1中，直接返回這個請求的promise，這樣可以由調用方決定到底該干什麼。
如下：
a.js
$(".okBtn").click(function() { b1(data).success(function(result) { $("someArea").html(_.template("tpl", result)); });});$(".okBtn1").click(function() { b1(data).success(function(result) { // ... });});
b.js
function b1(data) { return $.ajax(url, data);}
如果要對返回數據作統一處理，也可以很容易地在b1中，用promise重新封裝了返回出來，只不過這樣在a.js裡面，直接調用的就不是success，而是then了。
注意到這樣的代碼還有問題，比如說大量的全局函數，不模塊化，容易沖突。此外，沒有一個地方可以緩存一些共享數據，比如說這么一個場景：
界面上兩個塊M和N，其中，M初始載入並載入數據，N在初始的時候不載入，而是在某個按鈕點擊的時候載入，而M和N中各有一個列表，數據來源於同一個服務端請求。
現在就有個問題，當N載入的時候，它的數據怎麼來？比較老土的方式，肯定是載入N的時候，同時也再去請求一下數據，然後渲染到N上。
從一個角度看，如果說不重新請求，N的這個數據應當從哪裡來？從另外一個角度看，如果重新請求了，發現數據跟之前的產生了變更，是否要同步給M，怎麼同步給它？
我們看看類似Backbone這樣的框架，它能提供怎樣的機制呢？或者如果我們不用它，怎麼自己把這個分層封裝得更好一些？
首先，是建立一個數據模型，在它上面添加數據的緩存：
define("model", [], function() { var Model = { data: null, queryData : function(param, fromCache) { var defer = q.defer(); if (fromCache || this.data) { defer.resolve(this.data); } else { var self = this; this.ajax(url, param).success(function(result){ self.data = result; defer.resolve(result); }); } return defer.promise; } }; return Model;});
這么一來，我們在模型上作了數據的緩存，如果調用的時候加fromCache參數，就從緩存讀取，否則就請求新的。為了在兩種情況下，調用方介面能保持一致，把整個函數封裝成promise，以便接著調用。這里的模型定義成單例了，假定是全局唯一的，可以根據需要調整成可實例化的。
這個時候，視圖層就要封裝DOM和事件的關聯關系：
define("view", ["model"], function(Model) { function View(element) { this.element = element; this.element.selector(".okBtn").click(function() { var self = this; var fromCache = true; Model.queryData({}, false).then(function(result) { self.renderData(result); }); }); } View.prototype = { renderData: function(data) { this.element.selector("someArea").html(_.template("tpl", result)); } };});
這個時候，多個視圖實例的情況下，數據也能夠較好地利用。
這樣，前端寫這個View，後端寫Model，可以作這么個分工。
這個只是很簡陋的方式，在復雜場景下還有很多不足，在這里先不展開了。更復雜的場景也就是類似Web應用那種方式，稍後專門寫一篇來展開。
## 小結
我們再來回顧前後端分離所要解決的問題，是分離前端和業務開發人員的職責，這個方案怎麼定，是應當隨著團隊狀況來確定的。比如阿里前端厲害，人多勢眾，他的前端就要往後推，去佔領中間層。我們蘇寧這樣的公司，前端比較薄弱，只能在很多場景下，讓出中間層，否則戰線鋪太廣只能處處被動。
同一個中途島，在不同的形勢下，占還是不佔，是很考驗前端架構師的一個問題。
對阿里的這種實踐，我們會持續圍觀，尋找並創造合適的出手時機。
【rank的回答(4票)】:
簡單說下自己的看法。
前端不再繼續「單純」在 kissy 上下功夫，而可以考慮向後的延伸架構是一種前端的進步，這種前端架構將重定義阿里的前端工程師工作，很多互聯網公司比阿里先行一步。
這個思路與與最早阿里很多前端沒有碰後端（例如模板）有很大的關系，用 NodeJS 作中間層能解決現面臨的問題，是一種不限於解決當前問題的長遠解決方案。
具體是否能解決和解決得好，在於細節，不在新，而在過渡。如，如何過渡目前 NodeJS 與原來的數據交互，如何灰度過渡，工作量等。
平台化與介面化思路（後端數據介面以 Services 存在）讓 amazon 收益非淺，現在後端平台化介面化在大公司趨勢明顯。
平台化需要更多更快的應用層開發選型，NodeJS 是不錯的一種。NodeJS 雖然還是有些問題，但從信息面與我們自己的應用經驗來看，已有慢慢成為後端 WebApplication 的一種很好的選型方案的趨勢。
總的來說，是個趨勢。
【Hex的回答(1票)】:
我認為這就是所謂的大前端開發模式。模式確實是好模式，但是真正實踐起來，和後端工程師的溝通和協調也會遇到很多問題。
我做過的幾個項目都是採用這種大前端的開發模式，前端基於Transformers框架+CodeIgniter組成大前端，這樣確實可以很好的隔離前後端，項目可維護性大大提高。
【鄧欣欣的回答(1票)】:
上周去杭州玩了下，和之前的阿里同事做了些技術交流，發現這一年，阿里的前端在流程改進上下了很大功夫； 題主所說的中途島應該是 UDC 團隊做的，應該說思路不是很新鮮，國外有 ebay 向 nodejs 的轉型案例，國內之前也有網路音樂移動端的案例;
但對阿里前端來說，意義確是很重大，解決了合作流程中的一個很大問題：之前阿里的前端是只寫靜態 demo，寫完給開發套模板，開發不太懂 html，漏寫個標簽，然後找前端調試，一來一去很折騰，是個必須干但又是個沒啥技術含量的事； 中途島可以很好的解決這類蛋疼事，但是請不要認為前端就因此會後端了，無非是之前瀏覽器用 ajax 請求介面，現在咱用 node http去請求唄，框架做得牛逼點，統一適配出前端的ajax 介面也不是不可能呀~~，想想嘛，為啥要用 node 呢？ 牛逼直接寫 java 啊。。哈哈哈~
其他的 F2E 團隊也做些很不錯的流程改進工具，同樣不是很新鮮，但對阿里前端都是比較有意義的工具：
def： 項目構建與發布工具，與阿里的 gitlab， scm 整合，各種 腳手架，build，combo，發布，一條命令搞定，確實很方便；
dip：數據介面平台，定義業務線前後端數據格式的一個內部公共平台，基於 json-schema，好像也可以給你提供 mock 介面；
uitest：前端持續集成平台；之前這東西我是邊做邊吐槽的，似乎剛上線，類似 jenkis 這些，提交或者發布代碼時，先幫你跑一次測試用例；目前通用測試庫比較少。
Trace：好像是叫這個名字吧，監控平台，這個比較早就有了，用來監控各個業務線頁面的運行狀況並搜集各種用戶數據，如解析度，UA
我看來 def 和 dip 對阿里前端的作用會更大些，uitest 估計作用一般，阿里前端是不注重代碼質量的，測試用例也僅在幾個重要的直接影響交易的業務線會寫。
【許文敏的回答(0票)】:
確實不錯，從職責上來區分前後端分離才是王道，nodejs將成為前端工程師的基礎技能
【獵人豆豆的回答(0票)】:
不要把簡單的問題搞復雜，對於淘寶這樣規模的公司，有些牽一發而動全身的改動，最好是在權衡風險和收益後再決定，我們是技術的使用者，而不要被技術牽著鼻子走.
【羅正燁的回答(2票)】:
前面前端的大牛們都說了，我換個角度聊聊。
這么講吧，阿里的前端為什麼比其它公司走的遠，是因為他們有很多前端，還有很多不用寫大量業務邏輯的前端大牛。大牛的作用，就是折騰。阿里的前端工程師水平在自身領域實踐上已經跟得上後端。
但這個架構所謂的分離，其實是把很多原來前端不需要做的事攬到了自己的手上，增加前端架構師的KPI，讓前端做了更多的事，周報好寫。因為nodejs和前端都是js，所以學習成本並不算高，但是對一個技術人員的要求是比原來更高了。
但是，他們團隊有很多HC，有很多錢。。所以像我這種一個產品線只有一二個前端的，要是這么玩兒，招人跟不上不說，然後還可以把自己累死。
所以技術選型和架構這種事，還是要根據自己團隊的能力和招人啊。
③ 如何評價 Angular 2.0 Final Release 的發布
作者：徐飛
鏈接：http://www.hu.com/question/50666914/answer/122280198
來源：知乎
著作權歸作者所有，轉載請聯系作者獲得授權。
1. 從整體上講，ng2概念還是偏多的，但這不算問題，因為他面向的主要還是大型企業軟體用戶，這類群體根本不介意概念再多一些，也不怕設計模式，所以，如果是to C的場景，選擇它的可能性不會很大，但是在to B的場景中，或者一些內網應用，還是比較容易獲得一些認同的。
2. TypeScript。關於是不是要使用TS，不同的人有不同的見解，很多人覺得這是多此一舉，自找麻煩，但如果結合上面提到的它的目標受眾的話，還是有比較重要的價值的。這個群體普遍會覺得有類型約束會對生產力提高有幫助。
3. RxJS。它深度綁定的Rx，仍然是一個比較有爭議的東西，因為它概念上有一個接受門檻，對初學者並不友好，但仍然考慮它所面臨的群體，Rx在.net和Java開發者（尤其安卓開發者）中，普及程度要比在Web前端高多了，而且Rx本身帶來的很多優勢，能夠解決業務上的很多問題，尤其是大量的非同步過程組合的問題，此外，有了這么個東西，也可以不需要別的平台里的rex這類東西，就能處理好數據的流動和組件之間的通訊問題。如果能接受這些，那就能夠理解前面提到的TS的問題。如果寫RxJS，但是不用TS，那就太為難自己了。多個流組合之後的結果，如果能直接看到類型，對生產力還是比較有幫助的。
4. 組件編寫的語法。在這個點上，是存在不少爭議的，比如說，組件類是否應當是class這種形態？組件的實例化過程，是否也能跟正常的constructor這類東西混合在一起，以增加更多的控制力？Decorator的寫法是不是分離出一些東西，讓主流程更清晰？我個人是比較傾向於class的寫法，所以，我們mobile版，用的是vue，但是用了ts和rxjs，也使用了一些decorator，不注意看的話，可能會以為寫的是ng2。
5. Directive。我之前看到某些問題的回答下面，有人提到幾個問題：
- ng1引入的directive概念是完全沒用的
- ng2是不能跟jq結合，對jq很不友好的
我來解釋一下我的觀點，後面提到的directive特指attr形態的directive，因為在ng2裡面，component還是一種directive。這種attr directive是必要的，它存在的價值是對普通components的補充。因為在組件化體系裡，除了「組件」，還有「行為」，行為也是一種形式的組件。
舉例來說，如果是界面的組件化，普通人可能都很容易理解，無非就是按照功能切分界面塊，不管切得好不好，一般都能像模像樣。這時候我問你個問題，如果有一個行為：當滑鼠移動到某個組件上，這個組件就展示某種形態的邊框。這種應該在代碼中被定義成什麼東西？
所以，如果你從這個角度理解directive，就可以認識到，把這段東西封裝成一個directive，然後加到那些你想有特定行為的組件上，就可以完成想要的功能了。例如：
<button hover-border>a</button>
<todo-list hover-border></todo-list>
這里的hover-border就是一個directive，跟component是正交關系，作為組件的一個修飾，對其功能進行增強。
這時候我們再考慮下，ng體系是不是對jq很不友好？其實不然，你大可以在directive內部去基於dom做某些事情，只不過在ng1裡面，你是可以直接在這里用jq，而在ng2裡面，是使用ComponentRef, ContentChildren之類的東西去操作組件內部的DOM，並不影響使用jq的一些東西，在跟jq的結合容易程度上，ng跟vue肯定要比react好。
6. Pipe。這個東西，你也可以理解為對filter的一個改名，當然它能做的事情是要多不少的，我舉一個比較有價值的東西：async。這是干什麼的呢？
<todo-item *ngFor="let todo of todoList" [todo]="todo"></todo-item>
這句裡面，todoList是不是必須存在？如果不存在，我們是不是要預先定義佔位變數之類？不然就要寫ngIf來區分不存在的情況。（當然ng1裡面可以不寫，空對象異常會被框架吃掉，這是很方便，但是對排錯不利）。
但是藉助async這個pipe，你可以把這么幾種類型綁定過來：
<todo-item *ngFor="let todo of todoList$ | async" [todo]="todo"></todo-item>
這個todoList$可以是：
Todo[]
Promise<Todo[]>
Observable<Todo[]>
也就是說，你可以直接把一個非同步的東西綁來這里，它自動幫你做resolve或者subscribe之類的事，這樣你在組件類裡面就會比較省事了。如果你整個應用是深度使用了Rx的，那在這里省事的可不止一點點。為此，我們也在vue上面做了點改造，這樣移動版本也能用類似的方式在模板上綁定Observable。
7. DI和NgMole。說實話，對這兩個東西，我是有一定保留的。我當然也知道DI能讓很多事情變得方便，但是考慮到一個問題，在前端做DI，繞不開非同步載入這么一個坑，當DI和非同步載入碰到一起，就比較折騰了。如果說，為了這個，還需要在mole那裡再搞什麼factory，還要再考慮非同步什麼的，我心裡是有些抵觸的，所以對rc5這個版本非常不滿，因為這個版本把ng1的mole又用不同的方式拿回來了！
我理解它這么做的用意，除了解決非同步DI的問題，還用一定的方式去約束業務代碼，包括第三方庫的一些組織方式，從而盡可能避免命名空間沖突，比如說，組件在模板中使用時候的命名沖突，引入兩個庫，都有<my-button>組件這類問題。
但我覺得，這個事情還是沒法徹底解決，不光ng沒徹底解決，別的框架可能都沒嘗試解決。這也就是ng2團隊考慮得多的地方，因為他是站在一個大型軟體開發框架的角度去看待這些問題，這些東西可能勉強解決了那邊的問題，但同時，對小型應用的開發團隊帶來了很多麻煩。
另外，rc5因為引入了NgMole，所以依賴關系的定義也跑到mole這一級了，這讓我非常不滿，之前在組件上顯式定義所有依賴，哪怕連內置的ngFor，ngIf都要定義，我都能忍（當然後來不用了，可以指定到全局去），因為我這么麻煩地定義了組件之間的依賴關系，就可以精確跟蹤整個項目的依賴狀況，用一種圖形化的方式去看這些關系，類似這個：GitHub - manekinekko/angular2-dependencies-graph: A simple tool to draw a component dependencies graph of an Angular2 application. 這是非常有用的！然而現在只能跟蹤到mole級別了。
8. 數據的變更檢測機制。可能ng1的變更檢測已經比較變態了，因為他監控DOM事件、AJAX、定時器等等，在每個可能導致數據變更的地方去做數據比對，可能不少情況下，會導致性能的一些問題。在ng2裡面，它竟然是朝這個方向更加進一步了，用了zone這么bt的東西，監控更多東西。但是，注意到，這里它的變更檢測策略是不同的，不再會去傻傻檢測整個scope樹，因為這次沒有$scope這種東西了，數據是直接掛在組件這個級別的，所以有機會在數據變更的時候，禁用某個樹枝上的所有數據變更監測，從而提高效率。細節可以參照我們團隊太狼同學的這篇回答：https://www.hu.com/question/46662780/answer/102300661
9. 性能，所以，我也要提一下性能。為什麼這么晚提，因為這個東西沒那麼重要。只要能減少大多數無效的數據diff，性能都低不到哪裡去，只要性能在一個數量級，都不是大問題。現在，ng2，vue，react這些東西，性能其實是一個數量級的，糾結誰比誰快30%或者50%都沒有那麼重要的，該卡的地方，大家都卡，該流暢的時候，大家都流暢。適當優化自己的數據組織、渲染過程才是正道。另外，ng1也不慢啊，其實也在一個數量級上。這么多人不喜歡它，難道是因為性能？
10. 體積。雖然能搖樹，ng2的構建大小還是有些大，不過在to B這個場景，這不算問題。如果做mobile開發，直接打在應用內部，也沒什麼，那些做輕應用的要慎重。我們也是基於這個原因，在mobile版選擇了vue，沒有敢選它。
如果是做桌面軟體，配合electron使用的話，還是不錯的，這些都不用管。
其他么，有一些細節待探討，比如router只有Observable形態的介面，但是裡面有些東西又是轉成Promise之類，就不吐槽了。至於網路請求這塊，我們是自己做的，沒有用ng自己的，因為我們是這么一種搞法：
- 通用的數據層，ts ＋ rxjs構建，這層多做了很多事情，而且是視圖層框架無關
- PC端，ng2
- 移動端，vue + ts + rxjs （除了我們，估計你也找不出其他家這么用的）
④ Angular js 初學者該看什麼書
建議先把基本的知識過一遍，留下印象比較好。（其實一開始帶著問題去學也難受，問題太多了，帶著帶著就忘了）
1.推薦《angularjs權威教程》(它的英文名就是ng-book)，講的非常詳細，對初學者非常友好，而且內容還算新。至少我這本裡面有關於angular1.3的內容更新（現在1.3是最新穩定版）。而且譯者本身也是前端的大牛：趙望野、徐飛和basecss(何鵬飛)。這里我就不@了。
2.推薦但又不太推薦《精通angularjs》，個人覺得對初學不太有利，因為它的例子不完整，或者說很散，一個完整的例子被拆成很多片段，你得時常前前後後翻十來頁去看代碼的上下文。不過對於angular基礎概念都熟悉的人來說，可以接受吧……書還行吧……
3.視頻教程。前面有回答說淘寶有驚喜的，於是我淘寶了一下，發現所謂的視頻教程其實就是大漠窮秋老師在慕課網的授課教程 AngularJS實戰丨章節 其實是免費的，所以不必花冤枉錢了。另外，youtube上面也可以搜到一些入門教程，我看了幾個，還不錯。
⑤ vue，angular，avalon這三種MVVM框架之間有什麼優缺點
使用Object.defineProperties、 VBScript、 Object.observe，純事件驅動，兼容IE6，DOM的兼容性處理可與jQuery媲美，體積少 早期的四大MVVM框架，都有大公司引銜： angularjs google出品，思想來自flex，IoC， 臟檢測，自定義標簽，受限於綁定數
⑥ 有誰知道：當老闆開始懷疑總經理時，事事有些防備時，但是表面上又對他不錯，請問還能在這干嗎
成語故事----犯罪嫌疑人盜斧
曾幾何時有一個鄉下人，扔斧頭。他以為是鄰居的兒子偷了所以要注意世界各地人的言行，一舉一動，可想而知，人們像盜斧賊。後來，投擲斧頭斧頭，原來是在山谷中不慎丟失，前幾天他在山上的柴火。找到一把斧頭，他跑進一個鄰居的兒子，然後小心地看他一眼，怎麼樣一個小偷。
可疑鄰盜斧：不注重的事實根據的人，胡亂猜疑的事情。
揠苗助長
春節和春秋時期，宋國有一個農民，他總是懷疑作物的田間生長速度太慢，看看今天，明天，看，我覺得苗似乎總是沒有長。他想：有什麼辦法使它們更高，更快？
有一天，他來到田間地頭，苗一拉。的大苗，AA拉真的有很多的努力，他拉過苗，已經破舊，但他很高興。回到家裡還放言：「今天我累了，我幫助苗長高了幾英寸！聽了他的兒子，趕緊跑到田裡去看苗在田間地頭有枯萎
無望
周代位的清施凡主主詩，不僅，而且也很好的治理國事。後來，他協助，圍繞周厲王國事。然而，周禮不枉費交叉霸氣和變態違法的事情。叛徒所有Zhoumei各種請在主直言不諱地勸說弊端的政治事務中的列數，叛徒在周厲王耳邊說他的壞話。周厲王博，很累了，從那時起，叛徒庭外和解，其中博放在眼裡。主要表達厭惡，寫了一首詩，後來收入「詩經」批評的詩叛徒說：「各種邪惡，屢教不改！「
屢教不改：，生病服葯不能保存。後比喻不好的東西要省著點。
風和海浪
古代北方和南方宋將軍的狀態姓氏取名夏愨，他從小就很勇敢的和雄心勃勃的一天，闕叔叔問他是否有任何野心，卻回答說：「可借風，破萬里浪」是指：我有突破一切障礙向前發展，建立一個企業。闕經過辛勤工作和實踐，努力工作，並最終成為一個能征善戰的一般。
後來，人們用描述的「風和海浪」不怕困難和銳意進取的精神
5。一衣帶水
北方和南方，北方，北周代陳國和南方長江為界。
北周宰相楊戩，廢晝迪，當皇帝，建立了隋朝。
他決心要滅掉陳，他說：「我的父母在全國各地的人，是因為有是一個像她帶橫跨長江窄，就看著南方的人患有救不了他們？
後「一衣帶水相隔只有一條狹窄的水域作為一個比喻，非常接近的兩個
6山高山流水
彈簧和秋季時代，有個叫俞伯牙，精通音律，精湛的鋼琴演奏，是一位著名的音樂家俞伯牙年輕的時候好學，有分工虛高琴技達到水平，但他總覺得自己還不能出神入化性能的各種事物的感受。傳說中的老師知道他的想法，拉著他的船到中國東海的蓬萊島上，讓他欣賞大自然的風光，聆聽大海的波濤聲。掃描地平線伯牙，看到洶涌的海浪，噴激濺海鳥翻飛歌耳山和樹木，鬱郁蔥蔥，如入仙境一般的奇妙感覺油然而生，耳邊彷彿稍微自然和諧動聽的音樂，他無法幫助土地博雅的鋼琴演奏，聲音休閑反過來，大自然的美麗，到了鋼琴的聲音，體驗到前所未有的水平。老師告訴他：「你必須去學習。
夜博雅乘船游覽面對清風明月，他思緒萬千，他開始彈鋼琴，琴聲悠揚，漸入佳境。突然，他聽到哇雅文的聲音從船上岸邊，只見一個樵夫站在岸邊，他知道此人當即請樵夫音樂會在船上，興致勃勃地為他演奏。伯牙彈起贊美高山的曲調，樵夫說：「我真的很不錯！庄嚴肅穆，像一座巍峨的泰山！」當他被打的表現洶涌的波濤時，樵夫說：「太好了！寬廣浩盪，好像看見滾滾水，無邊無際的大海！「雅令人興奮的顏色，激動地說：」演唱會！你是我的靈魂伴侶。「樵夫鍾子期從此，他們成了很好的朋友。
故事出自「列子·湯問。成語」山流水「的比喻朋友或知己，也用來指音樂美麗
字師
指校正的文章一個非常關鍵的字老師
宋濤悅語言「，歷史的五代補」
唐時期，非常繁榮的時期，中國的封建社會，文學和藝術的發展也很發達，其中最具代表性的詩歌不僅是詩人，詩，而且在藝術含量都很高。
無數詩人的詩人叫齊一直在曠野雪後的一個冬天，他看到傲雪開放的梅花詩興大發，創作的「早梅」詩，詠誦早開在冬季梅花詩兩首寫：超越村，昨晚，開分行數是書面的，他感到非常滿意。
一個名叫鄭谷，齊詩後寫這首詩的意思是不是完全，所以他經過反復的思考推敲，雪這首詩改變：超越村，一個開放昨晚的雪，因為他認為，自號梅花分行是開放的，不能算是早梅花
鄭谷的這種變化，雖然只是應閱讀這個詞只有一個字母的變化，但同時盡顯「早梅」更恰當地描述問題的意義，詩的意境更加完美。齊鄭谷的變化佩服鄭谷，說是單詞'
8。奉獻
曾經有一個名為秋季熟練的棋手，他的棋藝高超。
秋季兩個學生一起學習下棋與他的學生之一非常集中精力專注與老師和其他不，他認為，學下棋很容易，並不需要認真對待。老師解釋，雖然他坐在那裡，眼睛喜歡看著一個棋子在他的心裡在想：如果到野外拍攝下來大雁，好一頓不錯。「，因為他總是胡思亂想心不在焉，老師的講解也沒聽進去
結果，雖然兩名學生與老師的教導，但一步前進很快成為一個國際象棋實力的手持式，和其他沒有學過一點點技巧。
回答者：的_文_WEN_ - 見習魔法師兩個2-25 13:29
你想要什麼
孫楊的兒子「，通過閱讀他的父親馬，索馬輕松，他拿著這本書找到一匹好馬。根據這本書中的照片，一事無成。書中所寫的特徵，尋找，終於找到了千里馬的特點，很像一隻蟾蜍蟾蜍書會很高興帶回家，對父親說：「爸爸，我找到一匹千里馬，但蹄子稍差。父親一看，哭笑不得，沒想到兒子竟如此愚笨，他幽默地說：「不幸的是，這匹馬是太喜歡跳拉車。」然後嘆了口氣，說：「所謂還找什麼你想要的。
南柯一夢成語
疑惑：描述一個很大的夢想，或者比喻徒勞喜悅。
成語的：唐李公佐「南柯太守傳
>成語：淳於棼唐朝一次，因為他喝醉了，忍不住在院子里的槐樹下分手，沒想到他睡著了，在夢中，他看到了楚懷王參拜派人來接他前往淮參拜，其次是他心愛的公主嫁給他，並送他到縣南柯太守
在這段時間里，淳於棼治理南柯來得好，也很欣賞王封爵他的五個兒子，兩個女兒出嫁王侯非常高，所以他懷參拜
後來，檀蘿國攻打南柯郡，淳於棼軍輸了，那麼他的妻子因重者不幸的是，這一切，不希望繼續住下去南柯郡淳於棼，返回首都。然而，在資本，有人說王淳於棼生病的國王之前沒有驗證，把他的孩子被捕，並把他帶回原來的家。淳於棼離開淮參拜，醒來時，我意識到，這是一個夢想。
不久，淳於棼在院子里的槐樹下發現蟻洞，洞在首爾的宮殿池推入在土壤中，他突然意識到，夢想看到淮參拜，是蟻洞，而最高的樹枝槐樹可能是縣，當他南柯太守。
淳於棼想起臨安夢珂，覺得這個世界是無常的，所謂的財富和名聲很容易消失了，他最後的冬宮門。
故事由明陽沉琳切割山短語的「按圖索驥」來指機械地按老辦法做的事情，我不知道的工作，也用來指跟進線索來看待事物。 （完）
。非法侵入
採石河一堆土，李白高年齡的名稱;
來回一首詩，魯班斧在前面。
這是一個詩人的明代「稱號的李白李白墓，是世界著名的唐代詩人千古名去世後，有多少文人墨客一直墓李白想待一會兒，詩歌表達內心的感受，他們的行為只能是附庸風雅，「魯班面前班門弄斧」太不自量力。
魯班魯戰國時期的人，他是一個良好的生產的緊湊型家電專家，人們稱他為「一個聰明的，民間社會一直被視為祖先的木匠，誰還敢使用魯班斧，炫耀技術的前端，也就是說，想在大行家面前展示自己的技能，這太卑微可笑的行為被稱為「魯班面前弄斧」，簡稱為「侵入」，俗話說「關公面前耍大刀」的意思差不多 BR p>其實，侵佔「的成語，早在唐代，它的原型文學家柳宗元有這一個在序言：」他媽的斧頭潘基文，斯里蘭卡迎燕耳門！ 「指用斧頭在魯班面前，表現能力，英人（遊行斧專家），皮厚。
成語有時被用來作為一個自嘲的字眼，這意味著，它不敢炫耀自己的技能，前面的專家
極其可疑
一天，樂廣請他的朋友在家裡，在酒店大堂喝朋友喝，我突然看見玻璃，一條蛇晃動的影子，他的心是很反感，或飲酒後喝到底，心臟不舒服，擔心健康家庭
每隔幾天發病，音樂廣泛聽到這個消息，一個朋友生病了，了解他的病的原因。樂廣想了想道：「絕對不會有蛇在杯子！於是，他喝了一天去檢查，原來，掛在牆上的巨大的大廳，用油漆顏色弓的弓的影子，恰好反映朋友讓玻璃時，岳光去，朋友解釋這些東西對他這個人疾病盡快明白其中的道理。
後來，人們比喻的「高度敏感」可疑，自相分爭，帶來打擾
馬馬
的<BR /傳說天上的馬神叫馬在世界上，它也被稱為熟練的識別伯樂相馬的利弊。
馬本名孫楊被稱為第一的，他是一個人的春秋。因為他的馬非常好，人們會忘了他原來的名字，乾脆稱他為伯樂，一直是現在的時間。
伯樂受國王委託，購買一千里的一天馬向王說明，千里馬罕見，這是不容易找到一個需要參觀，楚並不擔心，他盡力做好工作。
馬跑了幾個國家，尋訪豐富馬沿河北，民不聊生的名稱，但仍然沒有找到喜愛的好馬。一天，馬回到齊在路上看到馬拉鹽出行非常困難的陡坡上。馬累得呼呼喘氣，每一步都是非常困難的。馬馬向來親近，不由他來見馬馬走近，突然開始復甦睜大眼睛，大聲嘶鳴，好像要說話伯樂相馬立即從聲音判斷，這是一種罕見的馬
>
罕見
東漢末年，名人恆有才。當時，醫生也榮格，他特別贊賞，他推薦給漢獻帝時，他寫道：「皇室皇宮，將建成的寶藏。如果平衡的一代，罕見。
>漢獻帝怕做決定，榮格推薦表曹操曹操召見禰衡，愛他們，不料，禰衡蔑視曹操，他是很不禮貌的曹操派禰衡當鼓擊鼓助興的官員宴會的客人，下令他宓擊鼓邊誰知，同時大罵曹操，曹操是很尷尬的。恆曹操發送到荊州勸降劉飈，想採取殺劉表的手他認為劉彪禰衡的座上客，每個程序或宣布發布站在宓後來，禰衡劉飈不敬。劉飈送他到部黃作為一個秘書。宓平衡恃才傲慢，非常傲慢，後，終於殺了導致黃
短語「罕見」來形容非常罕見的，非常罕見的。稱贊
屢教不改
用於人才
周代凡貝絲·博詩不僅是一個清石，和良好的治理事務。後來，他協助周厲王側然而，國之大事。李周望飛橫跋扈，枉法亂摔東西。巴結博直言說服列數的政治事務的弊端，在周厲王耳邊說他的壞話。周厲王博，很疲憊的叛徒，叛徒的叛徒各種Zhoumei法院，看著博的主要表達的厭惡，寫了一首詩，後來收入「詩經」。叛徒襲擊詩說：「各種邪惡，屢教不改！ 「
無望」：生病用葯不能保存後比喻不好的事情，要省著點。
不學無術
漢武帝統治時期，大將軍霍光舉足輕重的大臣法庭，並贏得了信任的晉武帝司馬炎病危時，委託給他的幼子劉涪陵（趙一荻）去世後，霍光和他的助手，趙迪，李劉迅霍光成做皇帝軒霍光把握事務國家權力40年，根據西漢黃河，發現了不小的功勛。
繼承王位後，劉迅，李徐飛他的王後。霍光的妻子霍顯貪圖富貴的女人，她希望她的小女孩變成一個君主，女王林勛結婚，你拿女王的疾病，賄賂王後中毒亡的女醫生。致命的陷阱敗露，女性醫療監禁此事霍光的東西，事先什麼都不知道，霍告訴他。查獲恐怖活動，指責他的妻子做這種事情，他想去報案，但沒有受到懲罰的心他的妻子，想想之前思維或邪惡的隱藏下來的東西。霍光的亡，被告知的情況下，軒軒被派去調查。霍光的妻子聽到了，他的家人和親信商量對策，決定召集族人規劃叛亂，不想漏風軒出兵霍家包圍滿門抄斬
優點和缺點的東漢史學家班固在「漢書·霍光傳」霍光發表評論，說他是「不學無術，暗大理」意思是霍光讀書，沒有知識，並因此理解的主要原因短語「不學無術， 「，指沒有學問，技能
。
才高八斗
南謝靈運，一個寫了大量的山水詩作家，他是聰明，好學，讀了很多書，從小由他的祖父謝玄愛。
他出生於東晉太史家族，世界他鳳姐康粵贛標題，稱他為「謝康樂」他，作為諸侯，但沒有實權，被送到永嘉任何知府。謝靈運奇怪懷才不遇，往往留下的官方不管，但去山上玩水上。後來，他辭職搬到會稽，經常酗酒和與她的朋友的樂趣。當地太守派人勸他節制一些，他一氣之下一頓。然而，謝靈運山水詩寫的，但受到人們的喜愛。他寫的一首新詩，將立即被競爭的轉錄，並很快將經歷。
鄧文迪接到位後，他被召回了資本的官員，他的詩歌和書法贊譽為「寶」。謝靈運更自豪，他說：「世界上只有一石，曹子建獨佔八斗，我有一個水桶，世界被分為一桶水。」
短語「才高八斗」，從而來描述高度的文學天賦。
⑦ 如何看待前端民工徐飛加入螞蟻金服
冬季，螞蟻正忙著把潮濕的穀子曬干。 飢餓的蟬跑來，向他們乞討食物。 螞蟻問他：「你為什麼在夏天不去收集食物呢？」 蟬回答說：「那時沒有時間，我忙於唱美妙動聽的歌。」 螞蟻笑著說：「你夏季如要唱歌，那麼冬季就去跳舞吧。」
⑧ 可以通過什麼途徑了解前端研發的最新資訊
我覺得，前端的技術動態主要有以下幾個方向：
1、各種 tips，前端的思考、總結與觀察，新技術的介紹和技術經驗（多類似網站上的專欄，或者是會議上的一個 talk）
2、新玩具的教程，新項目的介紹（最好有 Github 鏈接）
3、新標準的發布與制定動態，各大瀏覽器團隊發布動態
4、知名開發者/團隊博客，或者一些零散的優秀博文
國外有很多很好的資訊網站,
前提, 英語要好!如果英語不好也沒關系，現在很多瀏覽器都帶翻譯功能。
先說說國外
JS-頭條-伯樂在線 ：更新速度很一般，質量層次不齊，但不影響伯樂是盛產好的翻譯文章的事實。
最新最熱-極客頭條：時間多的就看看這里吧。
Hacker News : HN很多人都清楚，基本上你的story在上面站幾個小時，就可以陸續幫你帶來上萬流量。但是由於上面各種信息都有，如果只是前端資訊的話，你就得認真分辨了。 好在用戶活躍度極高，可以幫你甄別出信息量大到爆炸的資訊。
這些信息來源質量很多是參差不齊的，不過看多了一般就會有辨別能力了。
不管是什麼東西最好都抱著批判性的思維去看，不要說什麼就信什麼，多一些思考和質疑，被坑的幾率就會低很多。