Framework vs library: what is the difference?

What it actually is

A library is code your app calls. You install it, import the two functions you need, and use them wherever you decide. A framework flips that relationship: it calls your code. It decides the folder layout, when your files run, and how a URL turns into a page. You write the parts it left blank for you.

Think of it as bricks versus a house frame. A library is a box of Lego bricks: you snap a few into whatever you were already building, and you can put the box away tomorrow. A framework is a house with the frame already up. The rooms are placed and the plumbing runs where it runs. Your job is finishing the interiors, and moving to a different house means packing everything and rebuilding, which is exactly why swapping frameworks mid-project hurts.

The naming out in the wild is messier than the definition. React describes itself as “the library for web and native user interfaces,” and that is accurate: it renders components and does little else. But React’s own docs recommend starting a new app with a framework, and the first one they list is Next.js, which calls itself “The React Framework for the Web” and supplies routing, data loading, and the build setup. So when a tutorial lumps React in with the frameworks, it is wrong on paper and close enough in practice. The React you meet usually arrives wearing a framework around it.

Why your AI just did this

Before your agent writes a single feature, it has to settle structural questions: where files go, and how URLs map to pages. Scaffolding a framework settles all of them at once, which is why “build me an app” starts with npx create-next-app@latest or npm create astro@latest rather than an empty folder. The framework also decides how your pages get built, static files or a live server, which is the SSR vs SSG question. Libraries come later, pulled in one at a time through npm as needs show up: one for dates, another for charts.

The word also appears when your agent explains why it will not move something. “That file is a framework convention” means the structure expects it at that exact path with that exact name. Rename app/page.tsx in a Next.js project, or move a page out of Astro’s src/pages/ folder, and the route quietly disappears, with no error in any code you wrote.

When you’ll run into it

The clearest sighting is your own package.json. The dependencies list names the framework you live in (next, astro, express) alongside a longer tail of libraries. Deploy platforms ask about it too: Vercel’s project setup has a “Framework Preset” dropdown, because the platform needs to know which build command to run and where the output lands. And when you start the dev server in a Next.js or Astro project, the startup banner names the framework and its version before your app even loads.

Here is a rough map of the tools you will meet most:

Tool	What it is	What it decides for you
React	Library (its own site’s word)	How components render
Next.js	Framework	Routing, file layout, rendering, build
Astro	Framework	The same jobs, tuned for content sites
Express	Framework, a deliberately small one	How your backend handles requests
Tailwind	Calls itself a CSS framework, behaves like a library	Styling classes you sprinkle where you want

Tailwind earns its odd row. The tagline says “utility-first CSS framework,” yet it imposes no structure on your app: you add classes where you choose, and stripping it out later would be tedious but would not collapse the project’s structure. The label a tool wears matters less than the question underneath. Does it call you, or do you call it?

What to check

• Open package.json and read the dependencies to learn which framework your project is built on; next, astro, or express is the tell
• Ask your agent what the framework decides for you (routing, file layout, build) before requesting structural changes, so you know which folders are load-bearing
• Search errors together with the framework’s name when they mention files you never created, like next.config.js or astro.config.mjs; generic JavaScript answers will miss
• Treat “let’s switch frameworks” as a rewrite quote, and ask which parts survive the move before agreeing
• Match any tutorial to your framework and its major version; instructions for one rarely map onto another

Say it like a dev

Instead of: “can we swap React for Vue real quick” Say: “We’re on Next.js, so that’s a migration. What would it cost, and which components survive as-is?”

Instead of: “install the framework for charts” Say: “Add a small charting library. The framework stays Next.js.”

Instead of: “there’s a folder I never made, can we delete it” Say: “Is src/pages/ a framework convention here? What breaks if we move files out of it?”