Trong thế giới phát triển JavaScript, việc theo đuổi tính tối giản đôi khi tạo ra những thư viện ưu tiên kích thước hơn chức năng. Một thư viện PubSub chỉ 149-byte gần đây đã làm dấy lên cuộc thảo luận sôi nổi giữa các nhà phát triển về sự đánh đổi giữa kích thước mã và ứng dụng thực tế.
EventTarget làm nền tảng cho PubSub
Thư viện được đề cập tận dụng API gốc của JavaScript là EventTarget để tạo ra thứ mà tác giả khẳng định là triển khai publish-subscribe nhỏ nhất có thể. Với chỉ 149 byte khi được thu gọn, nó nhỏ hơn các đối thủ cạnh tranh như nano-pubsub (194 bytes) và tiny-pubsub (401 bytes). Toàn bộ triển khai chỉ gồm ba dòng mã tạo ra các hàm toàn cục pub và sub được xây dựng dựa trên các API EventTarget và CustomEvent.
Mặc dù ấn tượng về sự ngắn gọn, các thành viên cộng đồng đã nêu lên những lo ngại sâu sắc về cách tiếp cận này. Một ưu điểm đáng chú ý là EventTarget sử dụng tham chiếu yếu (weak references) đến các trình nghe (listeners), giúp ngăn chặn rò rỉ bộ nhớ - một vấn đề phổ biến với các triển khai PubSub tùy chỉnh khi các trình nghe không được hủy đăng ký đúng cách.
Nếu các trình nghe của triển khai này không được hủy đăng ký, chúng không thể được thu gom rác, và trong mã nguồn thực tế điều đó có nghĩa là rò rỉ bộ nhớ là không thể tránh khỏi. EventDispatcher có tham chiếu yếu đến các trình nghe của nó, vì vậy nó không gặp vấn đề này.
So sánh kích thước của các thư viện PubSub:
- pico-pubsub: 149 bytes
- nano-pubsub: 194 bytes (lớn hơn khoảng 30%)
- tiny-pubsub: 401 bytes (lớn hơn gấp đôi so với nano-pubsub)
Các cân nhắc kỹ thuật quan trọng:
- EventTarget sử dụng tham chiếu yếu (weak references) đến các trình lắng nghe (giúp ngăn rò rỉ bộ nhớ)
- Việc bọc CustomEvent yêu cầu mã bổ sung tại các điểm gọi
- Hỗ trợ TypeScript đòi hỏi mã khai báo bổ sung
Quan ngại về thiết kế API
Nhiều nhà phát triển đặt câu hỏi liệu các lựa chọn thiết kế API của thư viện có hợp lý trong các ứng dụng thực tế hay không. Một chỉ trích chính tập trung vào cách thư viện truyền dữ liệu thông qua thuộc tính detail của đối tượng CustomEvent, yêu cầu các nhà phát triển phải giải nén dữ liệu này tại mọi điểm gọi với event.detail. Như một người bình luận đã lưu ý, điều này thực sự chuyển mã từ thư viện sang mọi nơi sử dụng nó, đi ngược lại với các nguyên tắc thiết kế thư viện tốt.
Việc thiếu hỗ trợ TypeScript cũng được ghi nhận là một hạn chế, mặc dù tác giả đã bao gồm một đoạn khai báo TypeScript như một giải pháp thay thế. Một số nhà phát triển đề xuất các triển khai thay thế vẫn duy trì kích thước nhỏ nhưng cung cấp kiểu dữ liệu tốt hơn và API trực quan hơn.
Câu hỏi về giá trị đề xuất
Cuộc thảo luận của cộng đồng cuối cùng xoay quanh một câu hỏi cơ bản: liệu thư viện này có cung cấp đủ giá trị để biện minh cho sự tồn tại của nó như một gói phần mềm hay không? Một số nhà phát triển so sánh nó với tranh cãi nổi tiếng về left-pad, cho rằng việc đóng gói một API gốc đơn giản như vậy có thể là không cần thiết.
Những người khác đánh giá cao khía cạnh giáo dục của dự án, lưu ý rằng nó đã giới thiệu cho họ API CustomEvent mà họ chưa quen trước đây. Một vài người bình luận thậm chí đề cập đến kế hoạch kết hợp các phương pháp tương tự trong dự án của họ, cho thấy rằng ngay cả những thư viện tối giản cũng có thể truyền cảm hứng cho các kỹ thuật mới.
Cuối cùng, thư viện nhỏ này đóng vai trò như một điểm khởi đầu cho cuộc trò chuyện về sự cân bằng giữa tính tối giản và tính thực tiễn trong phát triển JavaScript. Mặc dù kích thước 149-byte của nó có thể ấn tượng, cuộc thảo luận của cộng đồng nhấn mạnh rằng kích thước không phải là tất cả - thiết kế API, quản lý bộ nhớ và trải nghiệm nhà phát triển vẫn là những cân nhắc quan trọng khi đánh giá bất kỳ thư viện nào, dù nhỏ đến đâu.
Tham khảo: pico-pubsub