停止編寫Javascript框架吧。
Javascript框架就好像死亡和稅收一樣：終究不可避免它的存在。我確信如果我是那面牆上的一只蒼蠅，每次有人開始一個新的網頁項目時，第一個問題肯定是我們用的是哪個JS框架？這就是當今業內對JS框架的根深蒂固的思維模式。但事實上並不需要如此，相反的，需要停止使用JS框架。
我們來看看我們都有些什么。
Angular、Backbone和Ember，哎喲媽呀
很長一段時間內網頁平台、技術堆棧對於HTML+CSS+JS最簡潔的描述就是災難（缺少一個更好的解釋）。誰能忘記IE的盒子模型或層標簽？我相信我只用了這幾個詞就讓你們其中一些人一下子回到了那個不堪回首的網頁開發時代。
在很長一段時間里瀏覽器之間有一大堆的不一致，作為業內人士的我們不得不編寫框架來掩蓋這些問題。問題是連一些根本性問題，各瀏覽器之間都不一致，比如事件是怎樣傳播的或者支持什么標簽，所以每個框架不僅僅是彌補這些漏洞，還要設計他們自己的瀏覽器運行模型。實際上他們的模型，許多模型，因為你必須為事件傳播發明一個模型，為DOM發明一個模型等等。許多模型的發明創造還在繼續。所以編寫了一個個框架，每一個都如同一片雪花，上千上萬的花朵綻放了，給我們帶來了jQuery和Dojo和MochiKit和Ext JS和AngularJS和Backbone和Ember和React！在過去的十年里，我們已經炮制了一大堆JS框架。
但是在過去的十年中還有很多其他事情發生了；瀏覽器比之前更好了。瀏覽器對於標准的支持有了很大的改善，現在有些持續發展的瀏覽器：它們可以自動更新瀏覽器，每一個新版本都有更好的性能和對標准更好的適應。新標准如下：
我認為是時候重新思考下JS框架模型了。現在已經不再需要創造另一種方式了，使用HTML+CSS+JS就行了。
那么為什么我們還要編寫JS框架呢？我認為原因大概是慣性，這是種習慣。但是它的確不好使，它不像框架是有主動危害性的，對嗎？好吧，我們先來看看用網頁框架定義我所說的。實際上這是一個有梯度的代碼，它以一小段代碼開始，如同代碼的主旨，然后是大段大段的代碼匯總，再上升至庫，最后是框架。
主旨->庫->框架
框架不只是一個比較大的庫，框架還有與事件和DOM等互動的模型。那么為什么不用框架呢？
抽象性，框架的一個問題是他們的賣點，框架從平台中抽象出來，所以你可以關注在構建你的軟件上。問題是現在你有兩個系統需要學習，HTML+CSS+JS和框架。如果框架是一個完美的從網頁中抽離出來的如同平台一樣，你就不用越過框架，但是猜猜怎么着，框架不是那么完美。所以你必須知道HTML+CSS+JS，因為某些情況下你的程序不會像你想象中那樣運行，那么你就要一層一層的檢查框架，去查出哪出錯了。直到檢查到HTML+CSS+JS。
繪制冰山
框架就像個冰山，10%漂浮在水上面，開起來並不危險，那隱藏的90%才會要了你的命。事實上還有更多的apt，學習一個框架就像繪制一座冰山，為了使用框架你需要學習整座冰山，但最終運行的進程都是沒有意義的，因為冰山會融化的。
小部件，另一個框架的賣點就是你可以讀取訪問小部件的庫。但你的確不需要通過框架來訪問小部件，它們都應該是獨立的。一個很好的例子就是CodeMirror，一個用Javascript做的語法高亮顯示代碼編輯器。你可以在任何地方使用它，不需要框架。
用框架做小部件也會失去你之前所做的努力。記得所有那些你寫的MochiKit小部件嗎？對的，現在將其轉移到Ember或Angular，那些小部件還好使嗎？
數據綁定，說實話我從來沒需要過它，但是如果你需要，那么應該是庫，而不是框架。
框架的一個更長期的問題是框架終結時會成為silos，他們為框架A分割的landscape和小部件不能在框架B下運行。你的努力都白費了。
那么后框架世界是什么樣的？
HTML+CSS+JS是我的框架
基本理念是框架是不需要的，用HTML+CSS+JS的內部功能創建你的小部件。將整塊的材料分成正交分量，並可以任意組合。最終的碎片都可以在web組件的大傘下。
HTML導入、HTML模板、定制元素和Shadow DOM都是允許我們切斷框架核心、創建可再次使用的元素和功能的技術。更詳細、更好的介紹請參考以下文章和庫：
那么，我們創建<x-flipbox>，宣布勝利，然后回家？
不，用Web組件你需要做的第一件事就是針對此功能的膩子膏，如X-Tag和Polymer。對於這部分的需求隨着時間減少，因為瀏覽器將這些規格的實施具體化。
強調一點，這些膩子膏不是框架，采用他們自己的模型開發網頁，膩子膏可以使用HTML5模型。但是這並不是唯一需要的，在同一平台下還是有些細小的差異，因為現行標准，瀏覽器會在一些細小的方面產生偏差，這就需要膩子膏。MDN貌似需要很多代碼，因為文件經常包含短小的每個功能的膩子膏。
所以一個巨大的HTML 5的膩子膏庫是很好的，但更好的是我所謂的html-5-polyfill-o-matic，一組允許我通過bog標准HTML+JS寫Web組件，通過靜態分析或運行時的Object.observe分析完我的代碼后，它為我的項目產生一個精確的完整的HTML 5 膩子膏子集。
當我開始試着混合和匹配多個資源的Web組件和庫時，這類功能將會更為重要，比如一個X-Tag的<x-foo>和Polymer的<core-bar>，這意味着我要include這兩個膩子膏庫？（結果是不用）我到底該怎樣做才能得到這些定制元素？X-Tag和Brick都有定制捆綁生成器：
如果我開始創建定制元素，我需要創建我自己的定制捆綁嗎？我不認為那是個可擴展的想法，我相信我們需要習語和工具來處理這些是更好的辦法。這可能實際上意味着改變我們怎樣打開資源；一個“小部件”不是個項目，所以我們處理這些事情的方法要改變。的確，還是要把代碼放進Git，但你需要負擔一個GitHub項目嗎？如果有個東西比現在項目更小、更接近Gist是更合適的。我如何為我的項目最小化/硬化所有這些代碼成正確的格式？如同Asset Graph的東西可能是個很好的開始。
那么我們現在需要什么？
1、建立可重復使用的組件的習語和指導。
2、在這些習語下編譯、崩潰、運行等的工具，所有HTML、CSS和JS。
3、一個可擴展的HTML 5膩子膏(polyfill)，基於實際使用的全部或按比例縮小的。
這就是創建一個不需要學習最新的框架的最新模型的未來我們需要的，取而代之的，我們只直接與平台工作，拉入定制元素和庫來滿足特定需求，消耗時間創建應用，而不是標記冰山。
問答
問：為什么你討厭框架的作者。
答：我不討厭他們。我的一些最好的朋友也是框架作者。我承認有點靈感來自於你們已經毀了Javascript，開玩笑啦，但是，再一次重申，沒有嘲笑框架作者的意思。
問：在HTML 5里你不能做XXX，為了這個，你需要個框架。
答：首先，這不是個問題。第二，感謝指出這個事情。現在我們一起將這個完善起來，HTML 5 允許在沒有框架的情況下完成XXX。
問：但是XXX不是個框架，是個庫！
答：是的，正如我說的，它是個有梯度的代碼，從主旨到框架，你可能會畫下一條與我的稍有不同的界限。這是可以的，這不是關於某一種特定軟件的分類，是關於從框架中挪走。
問：我已經用了XXX和XXX很多年了。
答：再說一次，這不是個問題，但是無所謂了，這是對你好啊，你應該以良好的狀態來幫助別人。
問：所以每個人都需要重寫下拉菜單、表格、滑塊和觸發？
答：絕對不用，要點是有一種方法來創建這些元素，一種不用買一種特定框架的方法。
問：哥們，所有那些HTML導入都會降低我的站點的性能。
答：是的，如果你很天真的使用這些東西，它會的，這就是我為什么提到需要一個HTML、CSS和JS的編譯和崩潰的工具。
問：那么不建議我使用任何庫？
答：不是的，這不是我說的，我很仔細的描繪了庫和框架的分界線，一個庫提供可供其他庫使用的功能的正交。庫是可以用的，不過框架是我希望看見大家不再使用的。
問：但是我喜歡數據綁定！
答：許多人都喜歡，我只是表達一下我自己個人的喜好。我並沒有說你不應該使用數據綁定，但是你不需要使用一整個框架來獲得數據綁定，有單獨的庫來做這個。