What is the difference between a library and a framework?

The distinction is about who calls whom, and it is usually summarised as inversion of control.

With a library, you are in control. You write the application, and you call the library when you want something done. You decide the structure, the flow and the lifecycle. Swapping one library for another is usually a local change.

With a framework, the framework is in control. It provides the structure and calls your code at the points it defines. You fill in the gaps. This is sometimes called the Hollywood Principle — don't call us, we'll call you.

A concrete illustration. Using a date library, you call format(date) wherever you need it. Using a web framework, you define route handlers and the framework decides when to invoke them, having already handled listening, parsing, routing and serialising.

Why the difference matters practically:

Cost of change. Replacing a library is usually contained. Replacing a framework often means rewriting the application, because your code was shaped around its assumptions. This is the single most important consequence and worth weighing before adoption.

Freedom versus consistency. Frameworks make many decisions for you, which is genuinely valuable — fewer choices, established conventions, less that can be got wrong, and easier onboarding for people who already know it. The price is that doing something the framework did not anticipate ranges from awkward to impossible.

Learning curve. A library teaches you an API. A framework teaches you a worldview.

The boundary is not sharp. React is often called a library and behaves like a framework in that it controls rendering and calls your components. Express is minimal enough to feel like a library. Many projects sit on the spectrum rather than at either end.

A useful question when choosing: how hard would it be to leave?