選擇 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 的使用方式。
  • 說明文件是否為最新版本?有時會將文件維護視為次要工作。如果程式庫已更新,但說明文件未更新,可能會導致開發時間白費。
  • 說明文件是否完整,且提供多種格式?使用者指南、程式碼範例、參考說明文件、現場示範和教學課程都是實用的文件格式,可協助您使用程式庫或架構取得成功。

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

結論

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

另外,您不妨考慮程式庫與架構的其他方面,不過本文尚未重點說明:

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