在 JavaScript 開發領域，對極簡主義的追求有時會產生重視程式碼體積而非功能性的庫。最近，一個僅有 149 位元組的 PubSub 庫引發了開發者之間關於程式碼體積與實用性之間權衡的熱烈討論。
以 EventTarget 為基礎的 PubSub
這個備受關注的庫利用 JavaScript 原生的 EventTarget API 建立了據作者稱是可能最小的釋出-訂閱實現。經過壓縮後僅有 149 位元組，比競爭對手如 nano-pubsub（194 位元組）和 tiny-pubsub（401 位元組）更小。整個實現僅由三行程式碼組成，這些程式碼基於 EventTarget 和 CustomEvent API 建立了全域性的 pub 和 sub 函式。
雖然其簡潔性令人印象深刻，但社群成員對這種方法提出了一些深思熟慮的擔憂。一個被強調的重要優勢是 EventTarget 對其監聽器使用弱引用，這有助於防止記憶體洩漏——這是自定義 PubSub 實現中常見的問題，特別是當監聽器沒有正確取消訂閱時。
「如果這種實現的監聽器沒有被取消訂閱，它們就無法被垃圾回收，在實際的程式碼庫中，這意味著記憶體洩漏是不可避免的。EventDispatcher 對其監聽器有弱引用，所以它沒有這個問題。」
PubSub 庫的大小比較：
- pico-pubsub：149 位元組
- nano-pubsub：194 位元組（約大 30%）
- tiny-pubsub：401 位元組（超過 nano-pubsub 的兩倍大）
關鍵技術考慮因素：
- EventTarget 使用弱引用來引用監聽器（有助於防止記憶體洩漏）
- CustomEvent 封裝需要在呼叫站點額外的程式碼
- TypeScript 支援需要額外的宣告程式碼
API 設計問題
幾位開發者質疑該庫的 API 設計選擇是否在實際應用中有意義。一個主要批評點集中在庫如何透過 CustomEvent 物件的 detail 屬性傳遞資料，這要求開發者在每個呼叫點使用 event.detail 來解包資料。正如一位評論者所指出的，這實際上是將程式碼從庫轉移到了每個使用它的地方，這與良好的庫設計原則背道而馳。
缺乏 TypeScript 支援也被指出是一個侷限性，儘管作者確實包含了一個 TypeScript 宣告片段作為臨時解決方案。一些開發者建議了替代實現，這些實現在保持小體積的同時提供更好的型別支援和更直觀的 API。
價值主張問題
社群討論最終圍繞一個基本問題：這個庫是否提供了足夠的價值來證明其作為一個包存在的合理性？一些開發者將其比作臭名昭著的 left-pad 爭議，暗示包裝如此簡單的原生 API 可能是不必要的。
其他人則欣賞該專案的教育方面，指出它向他們介紹了他們以前不熟悉的 CustomEvent API。一些評論者甚至提到計劃在自己的專案中採用類似的方法，這表明即使是極簡庫也能啟發新技術。
最終，這個微型庫成為了關於 JavaScript 開發中極簡主義和實用性平衡的對話起點。雖然其 149 位元組的體積可能令人印象深刻，但社群討論強調體積並非一切——在評估任何庫時，無論多小，API 設計、記憶體管理和開發者體驗仍然是至關重要的考慮因素。
參考：pico-pubsub