摘要：我承認從搞笑文章你糟蹋了中得到了一點靈感，不過我要再次說明，我無意嘲笑框架作者。庫很好啊，我希望看到大家一致贊同遠離的是框架。

原文《No more JS frameworks》

中文版翻譯：老碼農

翻譯版: 日語

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 的 和來自Polymer 的 ，這種功能會變得更加重要。是不是這就意味著我必須引入它們兩者的補丁庫呢？ (看起來答案是否定的。) 我又要如何獲取這些定制元素呢？ X-Tag 和 Brick 兩者都有定制綁定生成器：

Brick 下載
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: 很多人都喜歡，我只是表達個人喜好罷了。我也沒有說 你 不應該使用數據綁定，我只是說你不需要為了實現數據綁定而運用一整個框架而已，有一些獨立的庫就可以做到了。

2014-05-09 by Joe Gregorio

相關文章
給網頁設計師和前端開發者看的前端性能優化
前端框架你究竟選什么
十大前端開發框架（上）
十大前端開發框架（下）
20個值得一試的JavaScript框架
LESS介紹及其與Sass的差異
關于前端框架的一些觀點
14個支持響應式設計的前端框架
編寫出色CSS代碼的13個建議
Web前端開發規范文檔你需要知道的事
【譯文】別再用JS框架了，首發于博客 - 伯樂在線。