我們不需要JavaScript框架

注* 作者 Bio ，現在Google工作。 作者不希望我們過多的依賴框架，最多使用一些庫。 PS: 庫用著不爽了可以換一個，框架能隨便換嗎？

停止寫JavaScript框架

JavaScript框架看起來像死亡和稅收一樣不可避免。我敢肯定每次有人開始一個新的web項目時，他們問的第一個問題的肯定是： 我們用的是什么JS框架?這真讓我著急上墻。 這就是JS框架在當今業界根深蒂固的現像。實際上，框架并不是非有不可，它需要停下來。

讓我們來先看看我們現在都有什么？

Angular 和 Backbone 和 Ember, 唉天哪

在相當長的一段時間內。網絡平臺的技術棧可以簡潔地描述為HTML + CSS + JS，是由于缺乏一個更好的詞嗎？誰也不會忘記IE瀏覽器模型造成的一場災難。我敢肯定，所有的Web開發者都會為這些黑暗的日子抽搐。

在 很長一段時間出現了一大堆的瀏覽器，和我們之間產生大量的矛盾，作為產業的前提，必須編寫框架，來繞過他們。問題是，在一些瀏覽器中，有一些根本問題也不 一致，如事件是如何傳播的，或者是標簽的支持。所以每一個框架，不僅掩蓋了這些不同，也實現了專屬于自己的瀏覽器的工作模式。其實這種模式是必然的，因為 你必須發明一種事件工作的通用模式，和如何與DOM交互的統一模型。因此，很多框架就這樣產生了，百花齊放??，給我們帶來了 jQuery，Dojo，MochiKit和Ext JS 和 AngularJS 和 Backbone 和 Ember 和 React.。在過去的十年里，我們一直在生產大量JS框架。

注 舊版IE的事件模型與標準冒泡模型是不一樣的

但過去的十年也有發生著一些別的事情;瀏覽器變得更好。他們對標準支持得更好，現在也有四季常青的瀏覽器：自動更新的瀏覽器，每個版本的功能更強大，支持更新的標準，如：

HTML Imports
Object.observe
Promises
HTML Templates

注 HTML Imorts 導入復用HTML代碼段的新特性， 參見規范（起草階段） ，示例：

<link rel="import" href="/imports/heart.html">

我認為現在是重新思考的JS框架模型的時候了。有必要去創造另一種做事的方式嗎？ 還是只需要使用純HTML+CSS+JS。

那么，為什么我們仍然寫新的JS框架？我認為很大一部分原因是因為慣性，這是習慣。但是，這不像框架有害的理由，對吧？好吧，讓我們首先確定什么是web框架。首先是一些簡單的代碼例子，到列出一些要點，再移動到越來越大的代碼集合，然后變成一個庫，最后形成框架：

gist（要點） -> library（庫） -> framework（框架）

框架不只是庫，他們有自己的模式，并且與DOM交互有統一的方式，所以為什么要避免框架？

Abstractions 抽象

嗯，這是框架通常的賣點之一，它們是抽象出來的平臺，這樣你就可以集中精力建設自己的軟件。問題是，現在你需要學習兩個系統： HTML + CSS + JS和框架。當然，如果該框架是Web平臺的一個抽象，你只需要會這個框架就夠了。但是有完美的抽象嗎？abstractions leak抽象泄漏 。所以，你還是需要知道HTML+ CSS+ JS，因為在某些時候你的程序將無法正常工作，你希望了解它實現的方式，你必須向下挖掘，通過該框架的所有層，然后弄清楚哪錯了，最終到達HTML + CSS + JS。

注* 抽象是面向對象分類所依據的原則，提取特殊/共性以便繼承復用，但做好的抽象永遠無法完全滿足以后變化的需求，目前面向接口/方面，模塊化，組件化的發展都在嘗試解決這個問題。 相關： 痛苦的Java程序員， 面向對象的缺陷

Mapping the iceberg （映射的冰山）

框架就像是一座冰山，有10％浮在水面上看起來并不危險，但下面卻隱藏著90％。事實上，這個比喻很貼切，學習框架就像是映射一座冰山，你需要了解整個過程才能使用，映射所有事情的努力可能是沒有意義的，因為冰山可能有一天就會融化化。

Widgets（部件）

框架的另一個賣點，你可以訪問小工具庫。不過說真的，你不應該采用一個框架，來訪問這些小部件，他們都應該是正交的，獨立的。今天的一個很好的例子是CodeMirror，基于JavaScript的語法高亮代碼編輯器。你可以用在任何地方，任何框架里。

還記得你寫的那些基于MochiKit的小部件嗎？是啊，當時他們看上去多么美好呀。現在呢？遷移到Ember 或 AngularJS怎么樣？

Data Binding(數據綁定)

老實說，我從來沒有需要過它，但如果你想使用他們，你應使用一個庫，而不是一個框架。

從長期來，框架的問題的問題是，他們最終會成為孤島，專為框架A設計的部件無法在框架B上工作。這樣會浪費精力。

那么一個后架構的世界會是什么樣子？

HTML + CSS + JS我的框架

我的基本的觀點是我們不需要框架，使用已經內置在HTML + CSS + JS中的能力，建立自己的小部件（Widgets）。沒有任何依賴，掰開任何一個都可以獨立工作。最后的步驟是，將他們在 Web Componetns中啟用。

注 HTML/CSS/JS不正是純天然的MVC結構嗎？ HTML -> Template, CSS -> View, JS -> Controler, JSON -> Model


HTML Imports, HTML Templates, Custom Elements 和 Shadow DOM 都是有利的技術，應該讓我們減小對框架的依賴，允許創建可重復使用的元素和功能。下面這些技術可以更好地實現這一點：

HTML Imports
Polymer
X-Tag
Bosonic

所以，我們都創建<X-flipbox>類似的東西，宣告勝利，然后回家？

注 brick-flipbox是一個創建自定義Web Componetns的示例項目， 示例， 使用這個Web組件的方法：

<brick-flipbox>
  <div>Front</div>
  <div>Back</div>
</brick-flipbox>

不，其實，你需要確保Web組件工作的第一件事是用polyfills來實現該功能，如X-Tag和Polymer。避免那些舊版流量器不支持的情況。

注* polyfill指是開發者希望瀏覽器能原生支持的一些新特性而寫的代碼(或者插件)。

有一點這里要強調的是，這些polyfills都不是介紹自己的模型來開發Web上的框架，它們在使用HTML5模型。但是，這并不是真正的唯一的需要，各個瀏覽器對標準的執行還有一些差異，這是我們需要polyfill的地方。 MDN ，是一個很有趣的社區，沒有太多的不必要的代碼，提供大量的文檔，和少量代碼實現的polyfills。

Q/A 問答

問：你為什么恨框架作者。

答：我不恨他們。我的一些最好的朋友也是寫框架的。你可以看看這篇文章： 你已經毀了JavaScript ， 再次強調，真的沒有嘲笑那些寫框架的。

問：在HTML5中你無法，因此你需要一個框架。

答：首先，這不是一個問題。其次，感謝您指出了這一點。現在，讓我們攜手合作，將功能添加到HTML5中，允許實現。

問：但是不是一個框架，這是一個庫！

答：是的，就像我說的，這是從 gist -> framework 的漸變，可能跟我畫的線條略有不同。沒關系，這不是任何一個特定軟件的分類，只是關于不依賴框架的故事。

問：我已經使用和和 很多年了

答：同樣，這不是一個問題，但無論如何，對你都有好處，可以幫助其他人。

問：所以每個人都需要重寫下拉菜單，標簽，滑塊和然后換成自己的？

答：絕對不是，問題是不需要依賴一個特定的框架的來創建這些元素。

問：哥們，所有的HTML imports會毀了我網站的性能。

答：是的，如果你天真地實施了所以這些東西，那就會的。這就是為什么我建議你需要工具來編譯所有的HTML，CSS和JS。

問：所以我不應該使用任何庫？

答：不，這不是我說的，我很謹慎地界定庫和框架之間的區別，庫（Library）提供一個個正交的功能，可與其他庫結合使用。庫是好的，我100％支持，我只希望你離開框架。

問：但我喜歡數據綁定！

答： 很多人都喜歡，我只是表達個人喜好。我不是說，你不應該使用數據綁定，而只是說你不需要采用整個框架來獲取數據綁定，也有獨立的綁定庫呀。

原文地址： bitworking.org
來自：http://ourjs.com/