Thanks, I was looking for something just like this today!

I was glancing around and landed on the page for the flyweight pattern.[1]

It looks like `addBook` is using the spread operator, which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern. It also attaches extra arbitrary properties, but still assigns the result to a `book` variable. I don't think this is a great example.

[1]: https://www.patterns.dev/vanilla/flyweight-pattern/

Edit: I forgot to give you kudos for all the effort it must have taken to create all this content, and I appreciate that you're making it available for free.

Love this! Just wanted to note that I think there’s a mistake on the flyweight pattern page’s example. You’re using getting a boolean with Set.has but treating it like a Book (as if you had used Set.get). I also don’t really understand how this saves memory if you’re spreading the result into a new object, but maybe someone here can enlighten me!

Looks great, time to add it to my bookmarks.

Anyone has other sites like these to share?

- Domain-driven design, design patterns, and antipatterns

https://deviq.com/

- Refactoring and Design Patterns

https://refactoring.guru/

- Standard Patterns in Choice-Based Games

https://heterogenoustasks.wordpress.com/2015/01/26/standard-...

The ones that actually match POSD (deep modules, small interfaces, lower complexity) and work great with plain functions are:

Module Pattern

Factory Pattern (factory functions)

Mediator / Middleware Pattern (as function pipelines)

Hooks Pattern (custom hooks, generalized)

Container / Presentational Pattern (implemented with function components + hooks)

Everything else is either neutral, UI-only, or fights POSD (Singleton, Mixin, etc.).

Patterns from that page you should treat skeptically for POSD

From Patterns.dev, for your POSD-style codebase I’d avoid or downplay:

Singleton Pattern → encourages global state and tight coupling. Patterns

Mixin Pattern → tends to increase interface surface and make dependencies opaque. Patterns

Observer Pattern → powerful, but event-based wiring can obscure data flow and increase “system complexity” (classic POSD warning). Patterns

fantastic resource! kindly add svelte design patterns too and sveltekit if you can

Does anyone remember the Yahoo design patterns library? It was mostly for UX pattern (eg: ways to "Rate an object") and it was really good.

Almost 20 years ago.. damn.

https://creativecommons.org/2006/02/14/yahoodesignpatternlib...

https://web.archive.org/web/20060221111812/http://developer....

They had a great comparison of the different behaviors leaderboards could encourage in users.

I wish people would stop promoting the singleton pattern: in almost every case I’ve seen, singletons are unnecessary tech debt and solve a problem that’s better solved with some form of dependency injection (and I don’t mean the XML/YAML monstrosities various frameworks force on you but rather constructor arguments or factory functions)