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

原文《No more JS frameworks》

中文版翻譯：老碼農(nóng)

翻譯版: 日語

JS 框架看上去就像死亡和納稅，必然發(fā)生，無法避免。如果我能變成一只蒼蠅趴在墻上，我就能確定每次啟動一個新項目的時候，他們討論的第一個問題肯定是：我們要用哪個 JS 框架？這種場景反映了當(dāng)今 JS 框架的角色在行業(yè)里是多么根深蒂固不可動搖。但其實這種形勢并非是必需的，而且實際上，這種做法需要制止。

  
讓我們先回顧一下我們是怎么一路走來的。

Angular 和 Backbone 還有 Ember，我滴個天哪。

長期以來，用最簡潔的 HTML+CSS+JS 方式表述的web 平臺，從技術(shù)棧的角度看是一場災(zāi)難。誰能忘記 IE 的盒子模型或者 layer 標(biāo)簽？我知道，那些例子會引出 web 開發(fā)中一些令你不堪回首的往事。

很長時間里，瀏覽器之間存在大量的不一致，而我們作為一個行業(yè)，只能靠編寫框架來糊裱一番。問題在于當(dāng)時在不同瀏覽器之間對于一些基本問題都存在爭議，例如事件如何傳播或支持哪些標(biāo)簽，導(dǎo)致每個框架不僅糊裱了缺陷，而且還設(shè)計了他們對于瀏覽器功能的模型。實際上他們自己的模型都是多個，因為你要發(fā)明事件傳播的模型，還有與 DOM 交互的模型，等等。這里邊有很多新發(fā)明。隨之出現(xiàn)了一些框架，然后聚沙成塔集腋成裘，就產(chǎn)生了大量諸如 jQuery 、Dojo、MochiKit 、ExtJS 、AngularJS 、Backbone 、Ember 和React 等等玩意兒。在過去的十年里，我們不停地折騰出了成堆的框架。

但是過去的十年里還發(fā)生了其他一些事：瀏覽器越來越好了。它們改善了對標(biāo)準(zhǔn)的支持，現(xiàn)在出現(xiàn)了自動更新的常青瀏覽器，它們的每個版本都比舊版本更適應(yīng)和符合標(biāo)準(zhǔn)。這些新標(biāo)準(zhǔn)比如：

HTML Imports
Object.observe
Promises
HTML Templates

我認(rèn)為現(xiàn)在是時候重新思考 JS 框架的模型了。做 Web 開發(fā)沒必要再發(fā)明其他的方法，只要使用 HTML+CSS+JS 就行了。

那么，為啥我們還在編寫 JS 框架呢？我覺得這很大程度上是因為慣性，它成了一個習(xí)慣了。不過，有人要說，這種習(xí)慣有那么糟糕么？框架看起來也并不是有害的，對不？嗯，讓我們先從我說的框架定義開始分析。實際上這些代碼是有個增強(qiáng)的梯度，從代碼小片段開始，例如 Gist，逐漸擴(kuò)大到越來越大的代碼集，形成了庫，最終產(chǎn)生了框架:

  
gist -> library -> framework

量變引起質(zhì)變，框架已經(jīng)不再僅僅是大型的庫，它們有自己的一套與事件、DOM 等交互的模型。那么，為啥要避免用框架呢？

抽象 框架的一個問題往往也是它們的賣點，那就是它們把平臺抽象了，這樣你就能集中精力寫你自己的軟件。問題是，現(xiàn)在你需要學(xué)習(xí)兩套開發(fā)系統(tǒng)，HTML+CSS+JS 和框架。當(dāng)然了，假如某個框架能做到把 web 平臺完全抽象化，那你就永遠(yuǎn)不需要涉足到框架之外，但是你猜怎么著？抽象也會泄露。所以你需要了解 HTML+CSS+JS，因為某些情況下你的程序不會按你所期望的方式工作，你需要深入框架內(nèi)部的各個層直到 HTML+CSS+JS，才能找到出錯的原因。

  
繪制冰山圖

一套框架就像一座冰山，浮在水面上的 10% 看起來并不危險，最終讓你船毀人亡的是隱藏在下面的那 90%。實際上更合適的一個比喻是，學(xué)習(xí)一套框架就像對一座冰山繪圖，也就是說，為了使用框架你必須學(xué)會框架里所有的內(nèi)容，花精力去把所有的內(nèi)容對應(yīng)到傳統(tǒng)的 HTML+CSS+JS，從長期來看這個過程毫無意義，因為冰山最終都會融化。

小組件 框架的另一個賣點是你可以獲得一個小組件的庫。可實際上，你并不是非要運用一套框架才能得到它們，它們應(yīng)該是和框架無關(guān)的獨立功能。這方面的一個好例子是 CodeMirror，這是一個用 Javascript 編寫的語法標(biāo)記代碼編輯器。你可以在任何地方使用它，無需任何框架。

給某個框架編寫小組件也是吃力不討好的事。還記得你在MochiKit 框架下編寫的那些小組件嗎？現(xiàn)在你轉(zhuǎn)移到 Ember或者 Angular后，它們還好用不？

數(shù)據(jù)綁定 老實說，我從來用不著它。不過如果你需要的話，它也應(yīng)該以庫的形式出現(xiàn)，而不是框架。

框架帶來的更長期的問題是它們最后變成一個一個地窖，把整個版圖分割成片，給A框架編寫的小組件無法在 B 框架下使用。這就是事倍功半。

那么問題就來了：后框架時代的世界是什么樣的呢？

  
HTML+CSS+JS 就是我的框架。

基本思路就是不再需要框架，使用 HTML+CSS+JS 中已經(jīng)包含的能力去編寫你的小組件就行了。把一塊塊巨石打散成獨立的、可以任意組合的組件。按這個原則最終劃分出的各塊組件都成為 Web 組件中的一部分。

HTML 引入, HTML 模板, 定制元素, 以及 Shadow DOM 都是有助于我們砍斷框架束縛的有力技術(shù)，使我們能夠產(chǎn)生可重用的元素和功能。要想更詳細(xì)地了解這些技術(shù)的情況，請參閱以下文章和庫：

HTML Imports
Polymer
X-Tag
Bosonic
那么，是不是說我們都可以創(chuàng)建 然后就萬事大吉了呢？

不，并不是這樣。運用 Web 組件 需要做的第一件事是填補那些功能，例如 X-Tag 和 Polymer。不過隨著瀏覽器逐漸填補對于這些規(guī)范的實現(xiàn)，這些工作的必要性會逐漸減少。

在這里需要強(qiáng)調(diào)的一點是這些補丁并不是指那些自創(chuàng)一套 Web 開發(fā)模型的框架，它們只需要應(yīng)用 HTML 5 模型就行了。但是那并不是真正唯一的需求，在 Web 平臺上仍然有微小的缺口，每個瀏覽器都在一些細(xì)節(jié)上偏離當(dāng)前的標(biāo)準(zhǔn)，這才是我們需要填補的地方。MDN 看起來已經(jīng)有很多所需的代碼了，因為其中的文檔經(jīng)常包含了短小的針對每個功能的補丁。

那么，一個巨大的 HTML 5 補丁庫也許不錯，但是更好的辦法是我稱之為 html-5-polyfill-o-matic 的一套工具，它讓我能通過標(biāo)準(zhǔn) HTML+JS 來編寫 Web 組件，然后分析我的代碼 — 通過靜態(tài)分析或者運行時的 Object.observe ，使它可以精準(zhǔn)地從完整 HTML 5 補丁中產(chǎn)生我的項目所需的一套子集。

如果我開始嘗試混合和匹配來自多個來源的 Web 組件 — 例如來自 X-Tag 的 和來自Polymer 的 ，這種功能會變得更加重要。是不是這就意味著我必須引入它們兩者的補丁庫呢？ (看起來答案是否定的。) 我又要如何獲取這些定制元素呢？ X-Tag 和 Brick 兩者都有定制綁定生成器：

Brick 下載
X-Tag 下載

如果我開始生成定制元素，我是否需要生成我自己的定制綁定器呢？我不認(rèn)為那是個可擴(kuò)展的思路，我相信我們需要能更好處理這類問題的慣例和工具。這實際上可能意味著改變我們進(jìn)行開源項目的方式，一個小工具并不是一個項目，所有我們處理這類問題的方法需要改變。當(dāng)然了，還是要把代碼放到 Git 里，但是你是否需要一個 GitHub 項目的整體開銷呢？可能更好的辦法是更輕量級、接近 Gist 的方式。我如何才能把vulcanize 里所有這些代碼壓縮成合適的形式用到我的項目里去？類似于 Asset Graph 的例子也許是個合適的起點。

那么，我們現(xiàn)在需要的是什么？

編寫可重用組件的慣例和指南。
在這些慣例下用來編譯和壓縮的工具。所有都是 HTML, CSS, 和 JS。
可擴(kuò)展的 HTML 5 補丁，根據(jù)實際需要來確定用完整的還是精簡版。
這就是我們在未來構(gòu)建Web應(yīng)用時所需要的一切。在那時，我們不再需要學(xué)習(xí)最新框架的最新模型，而是直接針對 Web 平臺工作，引入定制元素和庫來滿足特定需求，把時間花在編寫應(yīng)用上，而不是去繪制冰山圖。

Q&A
Q: 你為啥憎恨框架作者呢？

A: 我不憎恨他們。我有些最好的朋友就是框架作者。我承認(rèn)從搞笑文章《你糟蹋了 Javascript》中得到了一點靈感，不過我要再次說明，我無意嘲笑框架作者。

Q: 你可以用 HTML 5 實現(xiàn) ____ 功能，但為了這么做你需要一套框架

A: 首先，那不是一個問題。其次，感謝指出這一點?，F(xiàn)在讓我們一起努力增強(qiáng) HTML 5 的能力，讓____ 功能可以不用框架就能實現(xiàn)。

Q: 但是 ___ 并不是框架，它是一個庫!

A: 是的，正如我所說，它是從 gist 漸進(jìn)到框架的，可能你的劃分方式和我稍有區(qū)別。沒關(guān)系，這篇文章的重點不是對特定軟件的分類，而是遠(yuǎn)離框架。

Q: 我這么干活已經(jīng)很多年了，用了 ___ 和 ___ 還有 ___。

A: 這也不是一個問題。不過無論如何，這對你是有好處的，你應(yīng)該處在了幫助其他人的有利位置。

Q: 這么說每個人都需要重寫下拉菜單、標(biāo)簽頁、滑動條，并自己實現(xiàn)切換功能？

A: 絕對不是這樣，關(guān)鍵是應(yīng)該用一種不限定在某個框架的方式來創(chuàng)建這些元素。

Q: 伙計，所有這些 HTML 引入會把我網(wǎng)站的性能搞死的。

A: 是的，如果你在本地實現(xiàn)所有這些功能的話，這也是我前面 提到用來編譯和壓縮 HTML+CSS+JS 的工具的必要性 的原因。

Q: 那么我就不要用 任何 庫嘍？

A: 不，那不是我表達(dá)的意思。我在區(qū)分庫和框架這方面非常謹(jǐn)慎。庫提供的是可以配合其他庫使用的獨立功能塊。庫很好啊，我希望看到大家一致贊同遠(yuǎn)離的是 框架。

Q: 可是我喜歡數(shù)據(jù)綁定！

A: 很多人都喜歡，我只是表達(dá)個人喜好罷了。我也沒有說 你 不應(yīng)該使用數(shù)據(jù)綁定，我只是說你不需要為了實現(xiàn)數(shù)據(jù)綁定而運用一整個框架而已，有一些獨立的庫就可以做到了。

2014-05-09 by Joe Gregorio

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