譯文 別再用 JS 框架了

原文《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框架了，首發於博客 - 伯樂在線。