Why I still teach Singleton even though modules make it redundant

Ask any developer what design pattern they know best and Singleton comes up first. Ask the same group...

Ask any developer what design pattern they know best and Singleton comes up first. Ask the same group if they use it in production and half will say no. The module system already does the job.

They're right. But I still include it in my patterns reference, and here's why.

What Singleton actually solves

The pattern ensures a class has only one instance and provides a global access point to it. Shared configuration loaded from env vars, a logger that buffers output, a connection pool you don't want duplicated. That kind of thing.

The classical JavaScript version looks like this:

class Config {
  static #instance = null;
  #data;

  constructor() {
    this.#data = {
      apiUrl: process.env.API_URL ?? "http://localhost:3000",
      timeout: Number(process.env.TIMEOUT ?? 5000),
    };
  }

  static getInstance() {
    if (!Config.#instance) {
      Config.#instance = new Config();
    }
    return Config.#instance;
  }

  get(key) {
    return this.#data[key];
  }
}

Boilerplate. Every time.

The module alternative In JavaScript and Python, a module is already a singleton. The runtime caches it after the first import. So the same Config above becomes:

// config.js
export const config = {
  apiUrl: process.env.API_URL ?? "http://localhost:3000",
  timeout: Number(process.env.TIMEOUT ?? 5000),
};

// anywhere else
import { config } from "./config.js";

Same object, every import, no class, no getInstance(). Python works identically.

So the pattern is "redundant" in the sense that you'd rarely write the classical version in a modern JS or Python codebase. You'd just export a module-level object.

Why I still teach it

Three reasons.

You will read it in older code. Codebases written before ES modules were standard, Python 2-era code, Java and PHP services. If you've never seen the pattern explained properly, you'll waste time figuring out what the class is doing.

It makes the intent explicit. A plain exported object and a Singleton both enforce one instance, but the Singleton makes that constraint visible and enforced at the type level. In teams, explicit beats implicit.

Rust does not have the shortcut. OnceLock (stable since 1.70) or LazyLock (stable since 1.80) is the idiomatic way to get a static singleton in Rust. There is no module-level trick.

use std::sync::LazyLock;

static CONFIG: LazyLock<Config> = LazyLock::new(Config::from_env);

That is the pattern, just dressed in modern syntax.

The broader point

This is what I tried to do with the whole reference. For each of the 23 GoF patterns, show the classical approach and then show what modern language features replaced or simplified it. Some patterns are still essential. Some you'd only write in a language without the shortcut. Some you'll only encounter as a reader, not a writer.

The reference covers all 23 patterns plus the 5 SOLID principles, with examples in JavaScript, Python, and Rust. MIT licensed.

https://github.com/dsheiko/design-patterns-for-web-developer