選擇 JavaScript 程式庫或架構

烏瑪爾 (Umar Hansa)
Umar Hansa

本文將深入探討如何挑選要在網頁應用程式中使用的程式庫或架構。本文中的討論將協助您評估 JavaScript 程式庫或架構的優缺點,以找出要解決的業務問題。要檢驗各種可用的 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 提供許多功能,而且大小比其他選項更加合理。
  • 按照先前的 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。
  • 說明文件是否為最新資訊?文件維護有時就是事後補救的。如果程式庫已更新,但說明文件未更新,可能會導致開發時間浪費。
  • 這份說明文件是否完整且能以多種格式提供?使用手冊、程式碼範例、參考說明文件、現場示範和教學課程,都是具有價值的文件格式,可協助您運用程式庫或架構獲得良好成效。

技術文件不能總是完整,這樣沒關係。你必須評估貴機構的需求、專案需求及軟體複雜度,並據此決定所需的文件層級。

結語

第一次選擇程式庫或架構時,往往會感到不堪重負。就像處理其他事務一樣,越能學習並練習一項任務,就越能有效達到目的。下次選擇要使用的程式庫或架構時,不妨參考這篇文章。你可以將本文中的標題當做檢查清單使用。舉例來說,這個程式庫是否效能良好?這個程式庫是否符合我的網頁無障礙規範?

您可能想考慮其他程式庫和架構的部分,但不特別討論以下文章:

  • 擴充能力:運用自訂邏輯和/或行為擴充程式庫的難易程度為何?
  • 工具:在適用情況下,程式庫是否提供程式碼編輯器外掛程式、偵錯工具和建構系統外掛程式等工具?
  • 架構:簡潔的程式碼很重要,但整體架構是否合理?
  • 測試:專案是否有測試套件?專案網站是否使用徽章或指標,測試套件通過最新修訂版本?
  • 相容性:資料庫是否能與您目前使用的其他程式庫和/或架構順暢搭配運作?
  • 費用:架構的成本是多少?是開放原始碼服務,還是可供購買?
  • 別名指標:這項指標在條件清單中應該偏低,甚至完全遭到忽略,但您可以考慮將專案「投票」、代表專案的社群媒體帳戶,以及/或是專案頁面中待處理的錯誤/問題數量。