Patterns.dev

Overall reception of Patterns.dev

• Many praise it as a clear, well-laid-out, free resource for frontend patterns, useful for interviews and as a reference, and note it has “aged well.”
• Others find it superficial: “breadth but no depth,” feels like 2017-era JS, and missing a more rigorous “pattern language” structure that connects small patterns into larger systems.
• Some ask for additions (e.g., Svelte/SvelteKit, mobile-oriented examples) and for better navigation (table of contents).

Critique of the Flyweight pattern example

• Multiple commenters focus on the Flyweight page as flawed:
  • createBook is said to return either true or a Book, then addBook spreads the result into a new object.
  • Using the spread operator creates a new object and copies even “shared” fields (title, author, isbn), which undermines the core flyweight idea of not duplicating shared state.
  • A bug is pointed out: using Set.has (boolean) but treating the result like a Book; this only “works” because spreading a boolean into an object is effectively a no-op.
• Some argue shallow copies can still save memory, others counter that here you shouldn’t copy at all; several conclude the example is misleading or “a mess.”

Singleton pattern and POSD concerns

• Several commenters strongly dislike seeing Singleton first: they view it as globals with extra ceremony, unnecessary tech debt, often better replaced by dependency injection, context objects, or just explicit construction.
• Others note the site’s “Tradeoffs” section calls singleton an anti-pattern in JS and argue there are legitimate uses (e.g., ES modules, certain frameworks, Rails/Laravel/iOS patterns).
• A POSD (A Philosophy of Software Design)–inspired comment advises favoring patterns that support deep modules and simple interfaces (module, factory functions, middleware, hooks, container/presentational) and treating singleton, mixin, and observer with skepticism.

Broader discussion: when and how to use patterns

• Several emphasize patterns as vocabulary and teaching tools rather than prescriptions; overuse, especially by juniors, often leads to over-engineered, harder-to-maintain systems.
• Others stress that many patterns are workarounds for missing language features (e.g., Builder vs named arguments/defaults, Observer vs first-class functions) and that functional patterns and good data-structure choices often matter more.
• Experiences diverge: patterns can be very helpful in large enterprise .NET/Java systems, but porting the same patterns wholesale to JavaScript frequently produces “Java EE–style” complexity without clear benefit.

Related resources and historical context

• The thread collects many alternative pattern/design resources (refactoring sites, API design guidelines, cloud patterns, game programming patterns, deceptive design, component galleries).
• There’s nostalgic discussion of the old Yahoo Design Pattern Library and YUI/ExtJS, and of Alexander’s A Pattern Language and software-patterns literature that emphasize interconnected, problem-driven pattern catalogs.