選擇 JavaScript 程式庫或架構

Umar Hansa
Umar Hansa

本文將分享相關洞察資料,說明如何在網頁應用程式中挑選要使用的程式庫或架構。本篇文章的討論內容可協助您權衡利弊,找出適合您要解決的業務問題的 JavaScript 程式庫或架構。瞭解不同情況適用的優缺點,是篩選大量 JavaScript 程式庫的關鍵。

什麼是 JavaScript 程式庫?最簡單的說法是,JavaScript 程式庫是預先編寫的程式碼,您可以在專案程式碼中呼叫該程式庫,以執行特定工作。

本文主要提到「程式庫」。不過,許多討論內容也適用於架構。基本上,這兩者之間的差異可歸納如下:

  • 對於程式庫,應用程式程式碼會呼叫程式庫程式碼。
  • 在架構中,應用程式程式碼會由架構呼叫。

以下實用範例有助於說明兩者的差異。

呼叫 JavaScript 程式庫的範例

JavaScript 程式庫會執行特定工作,然後將控制權交還給應用程式。使用程式庫時,您可以控制應用程式流程,並選擇呼叫程式庫的時機。

在以下範例中,應用程式程式碼會從 lodash 程式庫匯入方法。函式完成後,控制權會傳回至應用程式。

import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello

執行 lodash.capitalize 方法時,系統會呼叫預先編寫的 JavaScript 程式碼,將字串的第一個字母改為大寫。

JavaScript 架構的使用範例

JavaScript 架構是預先定義的程式碼範本,可用於建構應用程式的行為。也就是說,當您使用架構時,架構會控管應用程式流程。如要使用架構,您必須編寫自訂應用程式程式碼,然後由架構呼叫應用程式程式碼。

以下範例顯示使用 Preact JavaScript 架構的程式碼片段:

import { createElement } from 'preact';

export default function App() {
  return (
    <p class="big">Hello World!</p>
  )
}

請注意,在這個範例中,架構會進一步控管您編寫的程式碼,在某些情況下,架構甚至會控管程式的執行時機。

為什麼要使用程式庫?

使用 JavaScript 程式庫可避免不必要的程式碼重複。程式庫可抽象化複雜的邏輯,例如日期操作或財務計算。程式庫還可協助您推出初始產品,而不需要從頭開始編寫所有程式碼,這可能需要花費一些時間。

部分用戶端 JavaScript 程式庫可協助抽象化網路平台的特殊情況。圖書館也可以做為學習工具。舉例來說,如果您不熟悉動畫緩和函式,程式庫的原始碼可以教您這類緩和效果的運作方式。

部分程式庫由大型公司支援,這些公司會投入時間和金錢,確保程式庫保持最新狀態並安全無虞。許多程式庫都附有詳細的說明文件,讓您和團隊快速熟悉程式庫的用法。

使用 JavaScript 程式庫可節省時間。

為什麼要關注程式庫使用情形?

從技術層面來說,您可以從頭開始開發網頁應用程式,但如果可以使用免費 (開放原始碼) 軟體,或購買長期可節省時間和金錢的解決方案,何必費心費力呢?市面上有許多 JavaScript 程式庫和架構可供使用,每個都提供獨特的解決問題方法,且各有不同特徵。例如:

  • 程式庫可以由內部人員編寫及維護,而非由第三方負責。
  • 程式庫可能擁有特定法律授權,因此適合或不適合您的網頁應用程式。
  • 程式庫可能過舊或未維護。
  • 程式庫可簡化一組複雜的工作,讓您節省大量時間和金錢。
  • 程式庫可在社群中廣泛使用,並且在開發人員之間廣為人知。

如您所想,不同特性對網頁應用程式的影響也不同。有時,您可能不必做出太深的決定,如果不喜歡某個程式庫,可以安全地換掉。不過,有時程式庫可能會對您的工作和網頁應用程式造成重大影響,因此建議您採用更明智的做法。

有些非用戶端 JavaScript 環境 (例如在伺服器上 (在雲端環境中執行) 或在 Raspberry Pi 上),您可能需要調整用於審查程式庫和架構的條件。

成效

請勿忽略 JavaScript 程式庫對用戶端網頁應用程式造成的效能影響。大型 JavaScript 程式庫可能會影響網頁的載入效能,請記住毫秒累積起來就是數百萬秒

請考慮以下使用 JavaScript 程式庫製作動畫的情況。某些程式庫可能會輕易增加數十 KB,在某些情況下甚至會增加數百 KB。由於瀏覽器需要下載、剖析、編譯及執行程式碼,因此這類 JavaScript 資源可能會大幅延遲網頁載入時間。

JavaScript 程式庫越大,對使用者的效能影響就越大。

評估或使用 JavaScript 程式庫或架構時,請考慮下列建議來改善效能:

  • 如果您使用的是大型 JavaScript 程式庫,請考慮改用較小的程式庫。舉例來說,date-fns 提供許多功能,且大小比其他選項更合理。
  • 如同前述的日期函式範例,請只匯入所需的函式,例如 import { format } from 'date-fns'。請務必搭配樹狀圖抖動使用這個方法,以便建構並傳送最少的 JavaScript 酬載給使用者。
  • 使用 Lighthouse 等效能測試工具,觀察使用特定 JavaScript 程式庫的效能效果。如果程式庫會讓網頁載入時間延遲一秒 (請務必在測試期間限制網路和 CPU),您可能需要重新評估所選程式庫。除了檢查網頁載入作業,請務必分析任何會從相關程式庫叫用程式的網頁行為,因為網頁載入效能並未提供完整資訊。
  • 如果程式庫作者歡迎您提出意見,請提交您對成效的觀察、建議,甚至是對專案的貢獻。這就是開放原始碼社群的優點!如果您決定捐款,可能需要先向雇主確認。
  • 使用自動化套件追蹤工具 (例如 bundlesize),監控程式庫是否有意外的大型更新。JavaScript 程式庫通常會隨著時間增加。新增功能、修正錯誤、極端案例等,都會增加程式庫的檔案大小。一旦您/您的團隊同意使用程式庫,更新程式庫可能就不會是問題,而且可能不會產生任何問題。這時就適合使用自動化功能。
  • 請查看您對程式庫的要求,並評估網路平台是否原生提供相同的功能。舉例來說,網路平台已提供顏色挑選器,因此您不必使用第三方 JavaScript 程式庫來實作相同功能。

安全性

使用第三方模組會帶來一些固有的安全性風險。網頁應用程式程式碼集內的惡意套件,可能會危害開發團隊和使用者的安全。

以發布至 NPM 生態系統的程式庫為例,這類套件可能合法。不過,隨著時間的推移,包裝盒可能會遭到破壞。

以下是使用或評估第三方程式碼時,可考慮的安全性提示:

  • 如果您使用 GitHub,請考慮使用程式碼的安全性服務,例如 Dependabot。或者,您也可以考慮使用其他服務掃描程式碼中的漏洞,例如 snyk.io
  • 建議您使用程式碼稽核服務,由工程師團隊手動稽核您使用的第三方程式碼。
  • 評估是否應將依附元件鎖定至特定版本,或是在版本控制中提交第三方程式碼。這有助於將依附元件鎖定至一個特定版本,而該版本應可視為安全。諷刺的是,這可能會對安全性造成反效果,因為您可能會錯過程式庫的重要更新。
  • 掃描專案首頁或 GitHub 頁面 (如有)。研究是否存在未解決的安全性問題,以及先前的安全性問題是否已在合理的時間範圍內解決。
  • 使用其他第三方程式碼的第三方程式碼,比起零依附元件的程式庫,可能會帶來更大的風險。請留意這項風險。

無障礙設定

您可能會想知道軟體程式庫與網頁無障礙的關係。雖然軟體程式庫可在不同環境中使用,但在以客戶端 JavaScript 為基礎的程式庫中,網路無障礙性就顯得非常重要。

以 JavaScript 為基礎的用戶端程式庫 (或架構) 可以提高或降低網站的無障礙程度。建議您使用第三方 JavaScript 程式庫,在網頁中加入圖片幻燈片。如果圖片幻燈片未考量網路無障礙設計,您可能會忽略這項重要功能,並發布缺少關鍵功能的產品,例如無法透過鍵盤操作的幻燈片!

  • 回應式排版外掛程式是否支援使用者放大或縮小網頁?
  • 檔案上傳工具外掛程式是否支援輔助裝置的檔案上傳功能?
  • 動畫程式庫是否支援偏好減少動作的使用者?
  • 互動式地圖外掛程式是否支援僅使用鍵盤操作?
  • 音訊播放器程式庫是否提供適當的螢幕閱讀器體驗?

我們認為,您身為網頁開發人員,必須盡力配合,才能符合這類無障礙設計規定。例如:

  • 如有任何缺少的功能,您可以在程式碼庫中實作這些功能,即使繼續使用相關程式庫也一樣。
  • 在雇主支援下,您可以將缺少的功能提供給程式庫 (如果程式庫作者允許這類貢獻)。
  • 您可以與程式庫作者進行對話,舉例來說,您是否有計劃推出這些無障礙功能?你是否同意這些內容屬於圖書館?
  • 針對熱門用途,您可以探索更容易存取的替代程式庫選項,這些選項可能存在,但較難找到。
  • 在極端情況下,您可能需要完全捨棄程式庫,並從頭實作功能。當程式庫或架構在初次使用時,提供的無障礙體驗不佳,而您需要撤銷許多程式庫或架構提供的免費功能時,就可能發生這種情況。

慣例

使用已建立的程式碼規則的軟體程式庫更容易使用。如果程式庫使用不常見的程式碼規則,您和團隊可能就難以使用這類程式庫。

如果程式庫未遵循常見的程式設計慣例 (例如常見的樣式指南),您無法立即採取任何行動來修正問題。不過,您仍有幾個選擇:

  • 請務必區分程式庫原始碼和向程式庫使用者 (您) 公開的 API。雖然內部原始程式碼可能會使用不熟悉的慣例,但如果 API (您與之互動的程式庫部分) 使用熟悉的慣例,那麼就無須擔心。
  • 如果程式庫 API 未遵循常見的程式設計規則,您可以使用 JavaScript 設計模式 (例如Proxy 模式),將與程式庫的所有互動包裝並納入程式碼庫中的單一檔案。這樣一來,Proxy 就能為程式碼集內的其他程式碼部分提供更直覺的 API。

慣例在易用性方面扮演重要角色。相較於需要大量實驗才能瞭解的反直覺 API,程式庫中的直覺 API 可節省許多人力小時,甚至是人力天數。

更新

舉例來說,如果是執行幾項數學運算的完整運作程式庫,這種程式庫可能很少需要更新。事實上,在不斷變化的網頁開發世界中,功能完整的程式庫可說是難得一見!不過,有時候您可能需要程式庫作者回應,並願意進行更新。新的研究和發現可能會揭露更佳的做事方式,因此程式庫和架構中使用的技巧也會隨之改變。

選擇程式庫或架構時,請留意更新的處理方式,並注意這類決定可能會對您造成的影響:

  • 程式庫是否有合理的發布時程?舉例來說,原始碼存放區的更新可能會經常發生,但如果這些更新沒有相應地「發布」或「釋出」,您可能會發現很難下載這些更新。
  • 程式庫是否會發布更新,並採用合理的軟體版本管理方案?程式庫應該可以節省您的時間。如果每次更新程式庫版本時,都必須意外變更程式碼,這可能會破壞使用該程式庫的初衷。有時會發生無法避免的重大變更,但在理想情況下,變更應不常見,且不會強制套用至程式庫使用者。
  • 程式庫是否投入回溯相容性的相關工作?有時,軟體更新可能會帶來破壞性變更,但也會提供一層回溯相容性。這樣一來,程式庫使用者就能在程式碼變更最少的情況下,使用最新的程式庫版本。

授權

軟體授權是使用第三方軟體程式庫的重要環節。程式庫作者可以將授權指派給程式庫。如果您考慮使用該程式庫,則授權選擇可能會影響您。

舉例來說,JavaScript 程式庫可能會有軟體授權,允許您在非商業環境中使用該程式庫。對於個人興趣專案而言,這可能是個不錯的選擇。如果專案含有商業元素,建議您考慮企業版授權。

如有疑問,請考慮尋求專業法律意見,或將問題交由貴公司法律團隊處理。

社群

擁有大量使用者/貢獻者的程式庫或架構可能會有所幫助,但這並非保證。一般來說,程式庫或架構的使用者人數越多,效益就越高。請考慮加入開發社群的優缺點:

優點:

  • 使用者人數越多,就越有可能及早發現並修正錯誤。
  • 活躍的社群成員人數越多,就代表有越多教學課程、指南、影片,甚至是課程,可供您針對相關程式庫或架構進行學習。
  • 活躍的社群成員越多,在論壇和問答網站上提供支援的機會就越多,也更有可能回答支援問題。
  • 社群參與度越高,程式庫或架構的外部貢獻者就會越多。他們可以協助提供作者路線圖中未列出的功能。
  • 如果某個程式庫或架構在社群中廣受歡迎,您的同儕和同事就更有可能聽過,甚至熟悉這類程式庫或架構。

缺點:

  • 擁有大量多元使用者族群的專案,可能會因不斷新增功能而變得臃腫。過度膨脹的程式庫可能會降低網站效能。
  • 擁有活躍社群的專案可能會對作者和維護者造成壓力,也可能需要大量的社群管理工作。
  • 如果專案發展迅速,但沒有適當的支援,就可能開始出現有害社群的跡象。舉例來說,初學者或初級網頁開發人員可能會因為門檻而覺得某個社群不歡迎他們。

說明文件

無論 JavaScript 程式庫或架構有多簡單或複雜,軟體文件總是能提供協助。即使是經驗豐富的開發人員,也都會使用說明文件,而不是自行判斷程式碼。說明文件會說明您應使用的 API,以及如何使用。

說明文件甚至可以提供程式碼範例,讓您更輕鬆地快速上手。評估程式庫或架構時,您可以問以下一些問題:

  • 程式庫是否包含文件?如果沒有,您就必須自行解決問題。
  • 說明文件是否清楚易懂,且沒有模糊不清之處?許多開發人員都花費大量時間製作說明文件。雖然這項功能看似微不足道,但文字說明的清晰度對工作效率有重大影響。
  • 說明文件是否完全由系統自動產生?這類說明文件不易消化,而且不一定會提供使用 API 的明確指南。
  • 說明文件是否為最新版本?有時會將文件維護視為次要工作。如果程式庫已更新,但說明文件未更新,可能會導致開發時間白費。
  • 說明文件是否完整,且提供多種格式?使用者指南、程式碼範例、參考說明文件、即時示範和教學課程都是實用的說明文件格式,有助於您順利使用程式庫或架構。

技術文件不一定會完整,這沒關係。您必須評估貴機構的需求、專案需求和軟體複雜度,並據此決定所需的文件等級。

結論

首次選擇程式庫或架構時,如果覺得不知所措,那是正常的。就像其他事情一樣,越常學習和練習某項工作,就越能掌握訣竅。下次選擇要使用的程式庫或架構時,不妨參考這篇文章。您可以將這篇文章中的標題當作檢查清單。例如:這個程式庫是否有效率?這個程式庫是否符合我的網站無障礙標準?

程式庫和架構還有其他方面值得您考慮,而這篇文章並未詳加討論:

  • 可擴充性:使用自訂邏輯和/或行為擴充程式庫的難易度為何?
  • 工具:如果適用,程式庫是否提供程式碼編輯器外掛程式、偵錯工具和建構系統外掛程式等工具?
  • 架構:乾淨的程式碼很重要,但程式庫的整體架構是否合理?
  • 測試:專案是否有測試套件?專案網站是否使用徽章或指標,指出測試套件通過最新修訂版本?
  • 相容性:程式庫是否能與您目前使用的其他程式庫和/或架構搭配使用?
  • 成本:架構的成本是多少?是開放原始碼還是可購買的產品?
  • 虛榮指標:這項指標應列在條件清單的下方,甚至完全忽略,但您可以考慮參考專案「票數」、代表專案的社群媒體帳戶,以及/或專案頁面有多少待解決的錯誤/問題。