Avoid Mini-Frameworks

What is a “mini-framework”? (Terminology & confusion)

• Several commenters note the post never clearly defines “mini-framework.”
• Many see them as ad-hoc, internal wrapper layers over existing tech (frameworks or libraries), adding new concepts and conventions on top.
• Others argue size is a red herring; the real distinction isn’t “mini vs macro” but good vs bad abstraction.
• There’s an extended side-debate on “library vs framework,” mostly converging on:
  • Library: you call it, no app lifecycle imposed.
  • Framework: it calls you, imposes structure via inversion of control.
• React is a lightning rod: some insist it’s “just a library,” others say it behaves like a framework in practice (DSL, lifecycle, hooks, culture).

Core problems with mini-/makeshift frameworks

• Often born from frustration with a core framework that can’t easily be changed or patched upstream (politics, OKRs, underfunded central teams).
• Add leaky abstractions that don’t cover all cases; you eventually must learn both the wrapper and the underlying system, increasing cognitive load.
• Tend to encode one team’s mental model, which doesn’t generalize; hard for others to adopt or reason about.
• Frequently under-documented, owned by one person or small group, and effectively die when authors leave.
• “Magic” behavior is praised early (fast onboarding, less boilerplate) but becomes a liability at scale and for edge cases and debugging.
• Seen as a manifestation of promotion / resume-driven development: building new “platforms” looks better than maintaining or improving shared infra.

Abstraction, DRY, and “magic”

• Strong sentiment: abstractions should reduce complexity, not just repetition. Over-DRY code can be harder to read and change.
• Suggested heuristic: do the painful thing many times first; let the right abstraction emerge.
• “Magic” is treated as a code smell when it hides control flow or constraints; “good magic” decomposes into understandable primitives.

When wrappers and frameworks are useful

• Wrappers can be justified to: shrink a huge API surface, enable substitution, ease upgrades, or improve testability.
• Industry frameworks like Rails, Django, Laravel are cited as examples where heavy “magic” and conventions can age well if there’s a dedicated team, ecosystem, and migrations.
• Some report long-lived, successful in-house mini-frameworks, arguing the real rule is: avoid abstractions that are hard to adapt and extend.