不要再使用JS框架了

postD_cn發表於2014-09-18
JS框架

　　停止編寫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的編譯和崩潰的工具。

　　問：那麼不建議我使用任何庫？

　　答：不是的，這不是我說的，我很仔細的描繪了庫和框架的分界線，一個庫提供可供其他庫使用的功能的正交。庫是可以用的，不過框架是我希望看見大家不再使用的。

　　問：但是我喜歡資料繫結！

　　答：許多人都喜歡，我只是表達一下我自己個人的喜好。我並沒有說你不應該使用資料繫結，但是你不需要使用一整個框架來獲得資料繫結，有單獨的庫來做這個。

　　原文：No more JS Frameworks byJoe Gregorio 翻譯：postd_cn

相關文章