DIV CSS 佈局教程網

 　　JavaScript世界似乎進入了一個churn rate(流失率)的危機，框架和技術在以一種不可持續的速度被擠出和消失。不過我認為社會將會適應以及采取新的實踐來回應這一現狀。開發者將會把目標從整理框架(如Angular.js和Ember)轉移到多種小型專用庫混合體，以此來緩解生產的風險並解決來自外部競爭的不同問題。

　　流失

　　2014年過去了，作為一個JavaScript開發者很難滿懷信心的去“挽回”一個特定的庫或技術，即便是強大的Angular，似乎也因為最近的一些事情而動搖。

　　2014年10月的ng-europe會議上，Angular開發者團隊透露了一個關於Angular 2.0路線圖的重大更新。而最有爭議的信息之一是NG2.0將與現有的Angular代碼“向後不兼容”。事實上，幾個關鍵的概念將在全新的體系結構中被棄用，Angular開發者需要有效的掌握全新的框架。

　　顯然，這一舉措令很多人感到不滿。是對還是錯?我們不太清楚，不過感覺上，Angular開發者在過去兩年裡的知識、實踐和代碼已經被任意的棄用了。更糟糕的是，替代品還不會馬上出現——這應該是一年以後的事了，反對者認為，一旦Angular 2.0在2015年發布的話，那麼開發者手中的新項目將經歷“由生到死”的命運。

　　有很多不快的評論專門指向Angular和谷歌，有些是中肯的，有些或許並非如此。但最高得票意見之一的並不是關於Angular。它指向整個JavaScript環境，Reddit的othermike評論道：

　　我不明白，我不明白為什麼有人認為這是一個好注意，這是很恐怖的，因為沒有人有時間去理解它，當它以每三十秒的速度改變。

　　othermike所反映的問題也正是流失的問題，有太多的JavaScript框架都改變的太快了。

　　這種變化的速度是可持續的嗎?

　　創新是偉大的，但是這種churn rate似乎過度了，當不能保證創新物的壽命時，不僅讓開發者不可能做大，也加大了前期時間投入——掌握處理新框架和技術。程序員想要創造事物，並且要成為事物的主人。但是當花費大量時間去學習時，程序員該如何完成事情?又如何通過不熟悉的技術在黑暗中探索?

　　無需絕望

　　情況是糟糕的，但是人是聰明的，開發者有夠足智多謀，而且編寫新應用的需求不會讓任何人放棄，那麼我們需要做些什麼呢?或許我們可以采取以下三個主要的經驗教訓：

　　以健康的懷疑態度對待新的技術。謹慎的將新的GitHub項目投入產品，等待一些事物被通用、錯誤修正以及被證明毫無疑問的成熟。

　　不要輕信於公司的支持。谷歌不是第一次對開發者所依賴的生態系統“釜底抽薪”。去問問那些使用Google的Web API的開發者就知道了。公司總會存在非理性的行為，他們的利益並不總是和你一致。

　　更傾向專門的庫而不是整體框架。當你選擇一個框架時，意味著你做了一個大的、長期的承諾。然而一旦框架被證明是錯誤的，你會失去很多，但是如果你從庫中選擇時，你可以替代一部分前端堆棧的同時保留其余部分。

　　庫>框架?

　　在Angular爭論的結果中，Reddit網站跟帖中有這麼個問題：JavaScript開發者感覺更喜歡遷移到哪個技術?這裡有r/javascript不得不說的：

　　React.js 和 Flux (一個只有視圖 view-only 的庫和事件驅動模塊)

　　Ember.js(MVC框架)

　　Knockout.js (視圖庫)

　　Backbone.js (MVC框架)

　　Meteor(同構框架)

　　Mithril(MVC框架)

　　Ember(MVC框架)

　　不要框架，只需要一堆庫就可以

　　Vue.js (視圖庫)

　　Breeze.js (數據庫Model-only)

　　Ractive (視圖庫)

　　有趣的是這裡有多少選項根本不是成熟的框架，而是專業的庫——主要用於數據綁定的DOM。有人提出：“在沒有整體框架，只有模塊化組件的情況下去做一件事情會比較好。”他是這麼說的：

　　我真的認為這是最好的答案。世上永遠不會有一個完美的框架，因此你僅可以使用npm將相關的特征聚在一起。我發現這些小的組件的文檔通常是很簡單的，你不需要去等待下一個完整框架的發布。你簡單的拋出一個問題，作者修復它，把它推到npm的同時不會打擾到其他組件。

　　如果你發現自己不喜歡制模語言或錯誤處理，你不必考慮整個項目，只需要以自己的方式換掉目前的組件。

　　不知你的感受如何?通過使用小型庫，讓選擇和混合成為可能。屆時，當它們被取代時，我們可以使用相近的來交換前端堆棧。庫不再是一個“非此即彼”的命題，如果你喜歡Angular的控制反轉容器，但不喜歡其數據綁定。你完全可以從NPM中選擇你喜歡數據綁定方式。你可以將你的遺留項目遞增的遷移到新的技術中，而不是重新寫一邊。

　　更重要的是，當不同的問題被不同的庫解答時，他們的解決方法可以直接比較。如果框架A用於X很好，用於Y很差，而框架B完全相反的時候，你會很困惑。不過如果庫A和B都試著用於X時，它們會以一種直接的方式在獨立部件和可衡量方面進行比較。

　　總結

　　前端JavaScript技術的流失率是有問題的

　　人們開始疲憊於改變的步伐，被迫疏遠

　　答案可能是“親庫而遠框架”

　　當然，在2015年我們將看到多少會實際發生呢?Angular的主導地位完全有可能繼續保持穩定，如果是這樣，Angular需要尋求標准以及穩定近兩年的“騷動”。當然也有另一種可能，就是會出現更龐大的事物代替Angular的位置。一個非正式的組合，Flux和Browserify似乎是很明顯的候選人。