The Hidden Cost of Including a Framework (Even a Minimal One)

It’s tempting. You’re in the middle of building something, an app, a script, a tool and you think, “Why not just include this tiny framework to speed things up?” Maybe it’s a minimalist CSS utility, a lightweight JS library, or a micro-framework for backend routing. It promises faster development and fewer headaches… right?

But even the smallest dependency has consequences.

Frameworks Are Dependencies and Dependencies Are Forever

The moment you include a framework, you’ve introduced a dependency. And that means:

• Versioning Risks: What works today might break tomorrow. Upgrading to the latest version may require you to refactor parts of your code. Sticking to an old version can introduce security vulnerabilities.
• API Drift: Minimal frameworks often evolve into larger ones. What began as a small helper tool can expand in scope, changing APIs and usage patterns along the way.
• Maintenance Burden: If the framework is abandoned by its maintainer—or worse, gets pulled from public repos—you could be stuck holding the bag. Remember left-pad?

Minimal Isn’t Always Minimal Forever

A tiny helper today could become a tangled web tomorrow. You may start relying on more of its features as your project grows. What once was a helper becomes the backbone of your architecture.

This kind of growth can lock you in, making it harder to swap out the dependency or migrate to a different solution later on.

Other Things You Inherit with a Framework

Including a framework doesn’t just mean extra files in your project. You’re also bringing along:

• Opinionated Structures: Frameworks often nudge you into certain ways of doing things. That can be helpful—or it can conflict with how your team wants to work.
• Performance Overhead: Even lightweight dependencies can add runtime costs, increase bundle sizes, or introduce latency.
• Security Surface Area: More dependencies mean more code to audit, more chances for vulnerabilities, and more third-party code running in your environment.

So… Never Use Frameworks?

Not at all. Frameworks are essential tools. But the key is to be intentional about your choices. Ask yourself:

• Is this dependency solving a real, repeating problem?
• Do I understand what it does under the hood?
• Can I remove or replace it later if needed?
• Does it fit the long-term vision of this project?

A Better Approach: Delay Commitment

When possible, start with vanilla code. Write your own small abstractions. See where the pain points are. Then, if a framework genuinely addresses a need you keep encountering, consider including it—but do it consciously.

Every framework, no matter how small, introduces weight—technical, organizational, and sometimes philosophical. That weight might be worth it. Just make sure you know you’re picking it up.