Remix.run Logo
android521 3 days ago

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

neogodless 2 days ago | parent [-]

What does POSD stand for?

jakubmazanec 2 days ago | parent | next [-]

I'm assuming John Ousterhout's book A Philosophy of Software Design [1], which I would recommend reading before reading about design patterns, because it's more fundamental.

[1] https://news.ycombinator.com/item?id=37975558

culi 2 days ago | parent | prev [-]

I'm assuming Philosophy of Software Design but I've never seen anyone blatantly presume it's an implicit initialism