2015年的JavaScript：Angular之類的框架將被庫取代
注* 本文表達了關于Angular和Ember這樣的整體性解決方案將被更小更專注的library(庫)這樣的觀點（有節選），之前的一些文章也表達過相似的論述：我們不需要JavaScript框架 , Angular.JS出了什么問題？
JavaScript 的世界似乎進入了流失率危機。新框架新技術以不可持續的速度推出并流行。但我認為，社會將適應并采取新的響應式做法。我相信開發者將從整體性框架 (frameworks)，如Angular.js和Ember等轉移到一系列小的，組合的，專業性庫(library)上面，以減輕流失的風險，并允許 解決方案，在不同的關注領域分別競爭。
JavaScript 的世界似乎進入了流失率危機。新框架新技術以不可持續的速度推出并流行。但我認為，社會將適應并采取新的響應式做法。我相信開發者將從整體性框架 (frameworks)，如Angular.js和Ember等轉移到一系列小的，組合的，專業性庫(library)上面，以減輕流失的風險，并允許 解決方案，在不同的關注領域分別競爭。
攪動
如
果你之前并沒有關注過<ng-community> angular社區，在2014年十月ng-europe
(歐洲）會議上，Angular開發團隊透露了一些有關Angular 2.0
顯著更新的路線圖。其中較具爭議的是，NG2.0將無法與現有的Angular代碼向后兼容。事實上，一些關鍵的概念將被擱置。Angular的開發將必
須掌握一個全新的框架。
可以理解，這打亂了很多人。不管正確與否，開發者在在過去兩年中如此努力獲取的知識，方法，經驗和代碼，現在已經被隨意棄用。更糟的是，更換甚至沒有任何過渡。新開項目將在十二個月之后2015年末發布，反對者覺得，Angular2.0可能“生下來就死”了。
老實說，無論Angular團隊在2.0版本做什么改動，我都會放棄它。強調離線功能，并放棄支持舊的瀏覽器讓新的東西聽起來很棒。
但這是一個爛攤子。語法看起來像狗屎，這與1.3之間的巨大差距意味著我們真正的就業機會，其中活了好多年的項目都打退堂鼓了。我不能告訴我的老板，我們要建立一些不可思議的，但我們需要規劃一個代碼而已，沒有新的特性，直到18個月改寫完代碼以后。
by jbarkett, Reddit 上發表的評論
有很多不快的評論專門指向Angular和谷歌 - 有些是中肯的，有些或許并非如此。但最高得票意見之一的并不是關于Angular。它指向整個JavaScript環境：
正 如許多人在這里看到的，時尚的Web開發，現在成為了一個笑話;我很認真很高興我找到了自己的方式。一旦你被迫對付這種沒有意義的東西，你要么尖叫著跑出 去或者去瘋狂迷戀。它甚至沒有碎片組合。我已經失去了對MV框架們的興趣，我將框架定義為“使用Foo，Bar和Baz”的組合，其中Foo是你從來沒有 聽說過的，有3％的使用份額的事件庫；Bar是你從來沒有聽說過的，有2％份額的模板庫；和Baz你從來沒有聽說過有1％的人使用的數據綁定庫，使得組合 有用？......我不知道，也許，作者在未來五分鐘，就會切換到一個新的庫。
我不明白。我不明白為什么有人認為這是一個好主意。我見過用這個東西所產生的代碼，它真是令人難以置信的可怕，因為沒有人有時間去了解，它在三十秒時間內所改變的任何東西。
by othermike, reddit
Othermike的問題，在我看來，真的是客戶流失的問題。有太多該死的JavaScript框架，它們改變的太他媽的快了。
兩
年前，JavaScript在燈火輝煌中慶祝自己的復興，得益于一個邁向更現代化，更規范的瀏覽器（例如不是Internet
Explorer）和Node.js的發展，作為一種用于前端構建的工具技術。新技術以不同方式出現了。只有12個月的時間似乎就成為事實，現代網絡將以
Backbone.js（也許用Marionette）為主，與Grunt作為任務驅動，Require.js和Handlebars作為基礎模板。然
而，半年過去了，這些技術都已經很明顯被取代，就像blogosphere那樣成為過去式了 -
現在，到處是關于關于Angular，Gulp和Browserify。現在這個堆棧似乎也值得商榷了。
這種變化的步伐能否持續？
我很坦率地承認對我不斷接觸到新技術不知所措。
by noname123 HackerNews
創
新是偉大的，但這種流失率似乎過高。作為開發者花費大量時間，去掌握新的框架和技術時，也不能保證他們的長壽。程序員要編寫 -
他們想建立的東西。但當我們花大部分的時間在學習新框架上，如何才能做出點東西呢？當我們在摸索與不熟悉的高新技術，我們怎樣才能像個工匠呢？
并非沒有希望
現實是嚴俊的。但人是聰明的，開發者足智多謀，寫出新的應用程序的基本要求是不讓任何人放棄它。那么，我們該怎么辦？
我覺得有我們可以總結出三個主要的經驗教訓：
- 對新技術持謹慎懷疑的態度。將那些很酷的新的Github上項目投入生產要小心一些。等到到普及了再開始采納。
- 不要太相信大企業做的東西。谷歌做這種事情已經不是第一次了。他們的利益并不總是和你的一樣。
- 寧 愿使用專用庫來代替整體框架。當你選擇了一個框架，你就做了了一個大的，長的承諾期限。您需要了解該框架內部各種運作方式和奇怪的行為。而你所掌握的東 西。如果該框架被證明是錯誤時，你會失去很多。但是，如果你從庫中選擇，你能負擔得起，庫是可以隨意更換的，你就有時間休息了。
Libraries（庫） > frameworks（框架）?
在Angular的爭議發生后，Reddit上的另一篇文章問：JavaScript開發人員應該遷移到什么技術。
下面是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 (視圖庫)
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！