What is a framework — and how it differs from a library

"Build it in React," "use the Next framework," "that's just a library" — these phrases rain down on a beginner from day one. And somewhere nearby there's always the question: is a framework the same as a library or not?

Here's the short difference that puts it all in place: you call a library, but a framework calls you. Sounds odd — let me show you why that's the key distinction.

What a framework is

A framework is a ready-made skeleton for an app. Its creators already decided the boring-but-mandatory things for you: how the app starts, how it's split into parts, how pages connect, where settings live. Your job is to fit your code into the prepared "empty rooms."

A real-world analogy. A library is a single tool in your box: a hammer, a drill. You grab it when you need it, then put it back. A framework is an already-built house frame: the walls stand, the wiring is laid, the rooms are marked out. You don't build the frame — you furnish what's inside.

How it works — "don't call us, we'll call you"

Here's that inverted bit. When you use a library, you're in charge: your code decides when to call its function. When you use a framework, it's in charge: its code decides when to call yours.

Picture getting hired. A library is a consultant you phone with a specific question. A framework is the company that hired you: "take your seat, we'll tell you when we need something from you." The famous line for this is exactly that: "don't call us — we'll call you."

In practice this means the framework dictates structure. Files go where it says. Functions are named the way it expects. Startup follows its rules. In return, you don't write the whole skeleton from scratch — and that's a huge saving.

Why it matters to you

When you build by vibe, choosing a framework is choosing a ready-made foundation. And that choice has two sides.

Upside: you don't reinvent the wheel. Startup, navigation between pages, the build step — all already work. The AI agent writing your code also knows the popular frameworks inside out and makes fewer mistakes in them.

Downside (or rather, the price): a framework imposes its rules. "However I like" won't fly — you do it "the way it's done here." For a beginner that's usually a plus: rules are guardrails that make it harder to drive into a ditch.

The takeaway that stays with you: a library is a helper you reach for on demand; a framework is a skeleton you slot into. Choosing a framework, you're choosing not a function but a way of life for your project.

Where you run into it

The most common one for the web is Next.js (a layer on top of React) for sites and apps. For the server side in Python — Django and FastAPI. When a builder like Lovable or v0 "builds you an app," under the hood it almost always sets up a framework — you just don't see it.

Framework or library — which should a beginner pick?

Most of the time the choice is made for you: you take a ready framework (or a builder takes it for you) and add libraries on top as needed. You rarely "choose a library versus a framework" on purpose — they work together, not instead of each other.

Is React a framework?

Formally React is a library: it only handles how the interface is drawn. But such an ecosystem grew around it (routing, building, Next.js on top) that in practice people often use it as a framework. People still argue about it — and for a beginner that difference isn't critical.