知識星球
JS框架看上去就像死亡和納稅，必然發生，無法避免。如果我能變成一隻蒼蠅趴在牆上，我就能確定每次啟動一個新專案的時候，他們討論的第一個問題肯定是：我們要用哪個JS框架？這種場景反映了當今JS框架的角色在行業裡是多麼根深蒂固不可動搖。但其實這種形勢並非是必需的，而且實際上，這種做法需要制止。
讓我們先回顧一下我們是怎麼一路走來的。
Angular 和 Backbone 還有 Ember，我滴個天哪。
長期以來，用最簡潔的 HTML+CSS+JS 方式表述的web 平臺，從技術棧的角度看是一場災難。誰能忘記IE的盒子模型或者layer標簽？我知道，那些例子會引出web開發中一些令你不堪迴首的往事。
很長時間裡，瀏覽器之間存在大量的不一致，而我們作為一個行業，只能靠編寫框架來糊裱一番。問題在於當時在不同瀏覽器之間對於一些基本問題都存在爭議，例如事件如何傳播或支援哪些標簽，導致每個框架不僅糊裱了缺陷，而且還設計了他們對於瀏覽器功能的模型。實際上他們自己的模型都是多個，因為你要發明事件傳播的模型，還有與DOM互動的模型，等等。這裡邊有很多新發明。隨之出現了一些框架，然後聚沙成塔集腋成裘，就產生了大量諸如jQuery 、Dojo、MochiKit 、ExtJS 、AngularJS 、Backbone 、Ember 和React 等等玩意兒。在過去的十年裡，我們不停地折騰出了成堆的框架。
但是過去的十年裡還發生了其他一些事：瀏覽器越來越好了。它們改善了對標準的支援，現在出現了自動更新的常青瀏覽器，它們的每個版本都比舊版本更適應和符合標準。這些新標準比如：
-
HTML Imports
-
Object.observe
-
Promises
-
HTML Templates
我認為現在是時候重新思考JS框架的模型了。做Web 開發沒必要再發明其他的方法，只要使用 HTML+CSS+JS 就行了。
那麼，為啥我們還在編寫 JS 框架呢？我覺得這很大程度上是因為慣性，它成了一個習慣了。不過，有人要說，這種習慣有那麼糟糕麼？框架看起來也並不是有害的，對不？嗯，讓我們先從我說的框架定義開始分析。實際上這些程式碼是有個增強的梯度，從程式碼小片段開始，例如Gist，逐漸擴大到越來越大的程式碼集，形成了庫，最終產生了框架:
gist -> library -> framework
量變引起質變，框架已經不再僅僅是大型的庫，它們有自己的一套與事件、DOM等互動的模型。那麼，為啥要避免用框架呢？
抽象 框架的一個問題往往也是它們的賣點，那就是它們把平臺抽象了，這樣你就能集中精力寫你自己的軟體。問題是，現在你需要學習兩套開發系統，HTML+CSS+JS 和框架。當然了，假如某個框架能做到把web平臺完全抽象化，那你就永遠不需要涉足到框架之外，但是你猜怎麼著？ 抽象也會洩露。所以你需要瞭解 HTML+CSS+JS ，因為某些情況下你的程式不會按你所期望的方式工作，你需要深入框架內部的各個層直到 HTML+CSS+JS，才能找到出錯的原因。
繪製冰山圖
一套框架就像一座冰山，浮在水面上的10%看起來並不危險，最終讓你船毀人亡的是隱藏在下麵的那90%。實際上更合適的一個比喻是，學習一套框架就像對一座冰山繪圖，也就是說，為了使用框架你必須學會框架裡所有的內容，花精力去把所有的內容對應到傳統的 HTML+CSS+JS，從長期來看這個過程毫無意義，因為冰山最終都會融化。
小元件 框架的另一個賣點是你可以獲得一個小元件的庫。可實際上，你並不是非要運用一套框架才能得到它們，它們應該是和框架無關的獨立功能。這方面的一個好例子是 CodeMirror，這是一個用Javascript 編寫的語法標記程式碼編輯器。你可以在任何地方使用它，無需任何框架。
給某個框架編寫小元件也是吃力不討好的事。還記得你在MochiKit 框架下編寫的那些小元件嗎？現在你轉移到 Ember或者 Angular後，它們還好用不？
資料系結 老實說，我從來用不著它。不過如果你需要的話，它也應該以庫的形式出現，而不是框架。
框架帶來的更長期的問題是它們最後變成一個一個地窖，把整個版圖分割成片，給A框架編寫的小元件無法在B框架下使用。這就是事倍功半。
那麼問題就來了：後框架時代的世界是什麼樣的呢？
HTML+CSS+JS 就是我的框架。
基本思路就是不再需要框架，使用 HTML+CSS+JS 中已經包含的能力去編寫你的小元件就行了。把一塊塊巨石打散成獨立的、可以任意組合的元件。按這個原則最終劃分出的各塊元件都成為Web 元件中的一部分。
HTML 引入, HTML 模板, 定製元素, 以及 Shadow DOM 都是有助於我們砍斷框架束縛的有力技術，使我們能夠產生可重用的元素和功能。要想更詳細地瞭解這些技術的情況，請參閱以下文章和庫：
-
HTML Imports
-
Polymer
-
X-Tag
-
Bosonic
那麼，是不是說我們都可以建立
不，並不是這樣。運用 Web元件 需要做的第一件事是填補那些功能，例如 X-Tag 和 Polymer。不過隨著瀏覽器逐漸填補對於這些規範的實現，這些工作的必要性會逐漸減少。
在這裡需要強調的一點是這些補丁並不是指那些自創一套 Web 開發模型的框架，它們只需要應用HTML 5模型就行了。但是那並不是真正唯一的需求，在Web平臺上仍然有微小的缺口，每個瀏覽器都在一些細節上偏離當前的標準，這才是我們需要填補的地方。MDN 看起來已經有很多所需的程式碼了，因為其中的檔案經常包含了短小的針對每個功能的補丁。
那麼，一個巨大的 HTML 5 補丁庫也許不錯，但是更好的辦法是我稱之為 html-5-polyfill-o-matic 的一套工具，它讓我能透過標準HTML+JS 來編寫Web元件，然後分析我的程式碼 — 透過靜態分析或者執行時的 Object.observe ，使它可以精準地從完整HTML 5補丁中產生我的專案所需的一套子集。
如果我開始嘗試混合和匹配來自多個來源的Web元件 — 例如來自 X-Tag 的
如果我開始生成定製元素，我是否需要生成我自己的定製系結器呢？我不認為那是個可擴充套件的思路，我相信我們需要能更好處理這類問題的慣例和工具。這實際上可能意味著改變我們進行開源專案的方式，一個小工具並不是一個專案，所有我們處理這類問題的方法需要改變。當然了，還是要把程式碼放到Git裡，但是你是否需要一個GitHub專案的整體開銷呢？可能更好的辦法是更輕量級、接近Gist的方式。我如何才能把vulcanize 裡所有這些程式碼壓縮成合適的形式用到我的專案裡去？類似於 Asset Graph 的例子也許是個合適的起點。
那麼，我們現在需要的是什麼？
-
編寫可重用元件的慣例和指南。
-
在這些慣例下用來編譯和壓縮的工具。所有都是 HTML, CSS, 和 JS。
-
可擴充套件的 HTML 5 補丁，根據實際需要來確定用完整的還是精簡版。
這就是我們在未來構建Web應用時所需要的一切。在那時，我們不再需要學習最新框架的最新模型，而是直接針對Web 平臺工作，引入定製元素和庫來滿足特定需求，把時間花在編寫應用上，而不是去繪製冰山圖。
Q&A;
Q: 你為啥憎恨框架作者呢？
A: 我不憎恨他們。我有些最好的朋友就是框架作者。我承認從搞笑文章 《你已經毀了Javascript》 中得到了一點靈感，不過我要再次說明，我無意嘲笑框架作者。
Q: 你可以用HTML 5實現 ____ 功能，但為了這麼做你需要一套框架
A: 首先，那不是一個問題。其次，感謝指出這一點。現在讓我們一起努力增強HTML 5的能力，讓____ 功能可以不用框架就能實現。
Q: 但是 ___ 並不是框架，它是一個庫!
A: 是的，正如我所說，它是從gist 漸進到框架的，可能你的劃分方式和我稍有區別。沒關係，這篇文章的重點不是對特定軟體的分類，而是遠離框架。
Q: 我這麼幹活已經很多年了，用了 ___ 和 ___ 還有 ___。
A: 這也不是一個問題。不過無論如何，這對你是有好處的，你應該處在了幫助其他人的有利位置。
Q: 這麼說每個人都需要重寫下拉選單、標簽頁、滑動條，並自己實現切換功能？
A: 絕對不是這樣，關鍵是應該用一種不限定在某個框架的方式來建立這些元素。
Q: 夥計，所有這些 HTML 引入會把我網站的效能搞死的。
A: 是的，如果你在本地實現所有這些功能的話，這也是我前面 提到用來編譯和壓縮HTML+CSS+JS的工具的必要性 的原因。
Q: 那麼我就不要用 任何 庫嘍？
A: 不，那不是我表達的意思。我在區分庫和框架這方面非常謹慎。庫提供的是可以配合其他庫使用的獨立功能塊。庫很好啊，我希望看到大家一致贊同遠離的是 框架。
Q: 可是我喜歡資料系結！
A: 很多人都喜歡，我只是表達個人喜好罷了。我也沒有說 你 不應該使用資料系結，我只是說你不需要為了實現資料系結而運用一整個框架而已，有一些獨立的庫就可以做到了。
原文出處： Joe Gregorio
譯文出處： 伯樂線上 – 老碼農