In the world of JavaScript development, the pursuit of minimalism occasionally produces libraries that prioritize size over functionality. A recent 149-byte PubSub library has ignited a spirited discussion among developers about the trade-offs between code size and practical application.
EventTarget as a PubSub Foundation
The library in question leverages JavaScript's native EventTarget API to create what the author claims is the smallest possible publish-subscribe implementation. At just 149 bytes when minified, it undercuts competitors like nano-pubsub (194 bytes) and tiny-pubsub (401 bytes). The entire implementation consists of just three lines of code that create global pub and sub functions built on top of the EventTarget and CustomEvent APIs.
While impressive in its brevity, community members have raised thoughtful concerns about this approach. One significant advantage highlighted is that EventTarget uses weak references to its listeners, which helps prevent memory leaks - a common issue with custom PubSub implementations where listeners aren't properly unsubscribed.
If listeners of this implementation aren't unsubscribed they can't be garbage collected, and in a real world codebase that means memory leaks are inevitable. EventDispatcher has weak refs to its listeners, so it doesn't have this problem.
Size Comparison of PubSub Libraries:
- pico-pubsub: 149 bytes
- nano-pubsub: 194 bytes (~30% larger)
- tiny-pubsub: 401 bytes (more than twice the size of nano-pubsub)
Key Technical Considerations:
- EventTarget uses weak references to listeners (helps prevent memory leaks)
- CustomEvent wrapping requires extra code at call sites
- TypeScript support requires additional declaration code
API Design Concerns
Several developers questioned whether the library's API design choices make sense in practical applications. A key criticism centers on how the library passes data through the CustomEvent object's detail property, requiring developers to unwrap this data at every call site with event.detail. As one commenter noted, this effectively shifts code from the library to every place it's used, which runs counter to good library design principles.
The lack of TypeScript support was also noted as a limitation, though the author did include a TypeScript declaration snippet as a workaround. Some developers suggested alternative implementations that maintain small size while providing better typing and more intuitive APIs.
The Value Proposition Question
The community discussion ultimately circled around a fundamental question: does this library provide enough value to justify its existence as a package? Some developers likened it to the infamous left-pad controversy, suggesting that wrapping such a simple native API might be unnecessary.
Others appreciated the educational aspect of the project, noting that it introduced them to the CustomEvent API they weren't previously familiar with. A few commenters even mentioned plans to incorporate similar approaches in their own projects, showing that even minimal libraries can inspire new techniques.
In the end, this tiny library serves as a conversation starter about the balance between minimalism and practicality in JavaScript development. While its 149-byte footprint may be impressive, the community discussion highlights that size isn't everything - API design, memory management, and developer experience remain crucial considerations when evaluating any library, no matter how small.
Reference: pico-pubsub