Frontend · JavaScript · Coding Standards

The Singleton Pattern in 30 Lines of Vanilla JS: One Popup Manager to Rule Them All

By 嘟嘟0717 · Aug 11, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Scattered popup instances are a common source of state bugs in front-end applications. A Singleton manager is the smallest, most direct fix, and understanding its static-method gate teaches the global-state mindset that underpins larger state-management libraries.

Summary

Opening popups from multiple places in a page often leads to scattered, unmanageable instances when each trigger creates its own object. A 30-line vanilla JavaScript implementation shows how the Singleton pattern solves this by locking a single instance behind a static `getInstance()` method. The first call lazily creates the object; every subsequent call returns that same reference, so a popup list recorded in one place is immediately available everywhere else.

The code walks through the three-step template—store the instance on a static property, check if it exists, and provide a unified access point—while clarifying the distinction between static and instance methods that trips up beginners. Connecting the manager to a DOM button with `getElementById` and `addEventListener` demonstrates how any trigger on the page routes through the same Popup object.

Real projects often need to record and close all popups uniformly. Replacing scattered `new Popup()` calls with a Singleton centralizes that state, eliminating the bug where separate instances cannot find each other's windows.

Takeaways

— Calling `Popup.getInstance()` twice returns the same object; `a === b` evaluates to `true`.

— The Singleton template has three parts: a static property to hold the instance, an existence check, and a static `getInstance()` method as the only access point.

— Lazy initialization means the instance is not created until `getInstance()` is called for the first time, avoiding upfront resource use.

— Static methods are called on the class itself (`Popup.getInstance()`), while instance methods require a retrieved instance (`a.open(url)`).

— Binding the Singleton instance to a button via `addEventListener` routes every click through the same Popup object, centralizing window management.

— `window.open(url, '_blank')` opens the URL in a new browser tab.

Conclusions

The article identifies a real beginner pitfall: writing `open` as a static method breaks access to instance state, a mistake that stems from not internalizing the static-vs-instance boundary.

Singleton's testability problem is acknowledged honestly—global state couples the instance to everything, and the article points readers toward dependency injection and module-level singletons as mitigations rather than pretending the pattern has no trade-offs.

Concepts & terms

Singleton Pattern

A design pattern that restricts a class to a single instance and provides a global point of access to it, typically via a static method that lazily creates the instance on first call.

Lazy Initialization

The tactic of delaying object creation until the moment it is first needed, rather than at program start or class definition time, to conserve resources.

Static Method vs. Instance Method

A static method belongs to the class itself and is called on the class name (e.g., `Popup.getInstance()`). An instance method operates on a specific object and must be called on an instance (e.g., `a.open()`).

Source: juejin.cn ↗ Google Translate ↗ Backup ↗