歡迎光臨
每天分享高質量文章

別再用JavaScript框架了

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 兩者都有定製系結生成器。

如果我開始生成定製元素,我是否需要生成我自己的定製系結器呢?我不認為那是個可擴充套件的思路,我相信我們需要能更好處理這類問題的慣例和工具。這實際上可能意味著改變我們進行開源專案的方式,一個小工具並不是一個專案,所有我們處理這類問題的方法需要改變。當然了,還是要把程式碼放到Git裡,但是你是否需要一個GitHub專案的整體開銷呢?可能更好的辦法是更輕量級、接近Gist的方式。我如何才能把vulcanize 裡所有這些程式碼壓縮成合適的形式用到我的專案裡去?類似於 Asset Graph 的例子也許是個合適的起點。

那麼,我們現在需要的是什麼?

  1. 編寫可重用元件的慣例和指南。

  2. 在這些慣例下用來編譯和壓縮的工具。所有都是 HTML, CSS, 和 JS。

  3. 可擴充套件的 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: 很多人都喜歡,我只是表達個人喜好罷了。我也沒有說 你 不應該使用資料系結,我只是說你不需要為了實現資料系結而運用一整個框架而已,有一些獨立的庫就可以做到了。

原文出處: Joe Gregorio

譯文出處: 伯樂線上 – 老碼農

贊(0)

分享創造快樂