Libraries, Frameworks and Packages | IT Foundations for Beginners

In this chapter

We'll learn why almost every app is built mostly from other people's code — libraries, frameworks and dependencies — and how packages, package managers, SDKs and APIs make that possible.

12–14 min

The Problem in Real Life

Anna looks inside the node_modules folder that npm install created. It has more than a thousand folders: react, express, stripe, date-fns, zod... The folder is bigger than the rest of the project put together.

"Did our team write all of this?" she asks. John laughs. "We wrote maybe five percent of the code that runs when someone buys a ticket. The rest was written by thousands of other developers. That's normal."

Nobody builds software from scratch. We all stand on other people's code.

John

Writing Everything Yourself vs. Reusing Proven Code

Most code isn't yours

Modern apps are mostly built from ready-made code written by others.

Dependencies have dependencies

Each library you install can bring in many more libraries of its own.

Many words for reused code

Library, framework, package, SDK, API — they're related but not the same thing.

Libraries, Frameworks, Packages and More

Think about what BlueTicket's checkout needs: handle web requests, check that an email address looks valid, format dates in every country's style, talk to a payment company, create QR codes. Writing all of that from zero would take years — and it would have more bugs than code that millions of people already use. So developers reuse code.

Library — ready-made code you call when you need it. Your code is in charge; the library is a toolbox. Example: a date library — your code calls format(date) and gets back "Sat, 14 Nov".
Framework — a bigger structure that your code fits into. The framework is in charge and calls your code at the right moments. Example: a web framework decides how requests arrive and calls your function for the /checkout page. A simple way to remember: you call a library; a framework calls you.
Dependency — any outside code your project needs in order to work. If BlueTicket uses a QR library, that library is a dependency. Dependencies often have their own dependencies (called transitive dependencies) — that's how 30 direct dependencies became 1,000 folders.
Package — a library (or tool) bundled up with a name, a version number and a list of its own dependencies, ready to install. Example: the package date-fns, version 3.6.0.
Package manager — a tool that downloads packages, installs the right versions, and installs their dependencies too. JavaScript uses npm, Python uses pip, Java uses Maven or Gradle. Packages come from an online store called a registry, like npmjs.com or PyPI.
SDK (Software Development Kit) — a complete set of tools for building on one platform or service: libraries, code examples, documentation and sometimes special tools. The Android SDK is for building Android apps; a payment company's SDK makes it easy to take payments from your code.
API (Application Programming Interface) — the set of rules for how one piece of software can ask another to do something: which requests you can make, what you must send, and what you get back. A library's API is its list of functions. A web API (Acts 12 and 23) is a list of web addresses you can send requests to. The payment SDK uses the payment company's API underneath.

Table — Library vs. framework

Feature	Library	Framework
Who is in charge?	Your code	The framework
How you use it	You call its functions when needed	You fill in the parts it asks for
Size	Usually small and focused	Usually large, shapes the whole app
Examples	date-fns, a QR code library	Next.js, Django, Spring, Express

Table — The words, side by side

Word	In one sentence	Example
Library	Reusable code you call	A library that makes QR codes
Framework	A structure that calls your code	A web framework
Dependency	Outside code your project needs	The QR library, for BlueTicket
Package	Reusable code with a name and version	qrcode@1.5.3
Package manager	Installs packages and their dependencies	npm, pip, Maven
SDK	A full toolkit for one platform	Android SDK, a payment SDK
API	The rules for asking software to do something	A payment company's web API

This file lists the packages a JavaScript project depends on, with the versions it accepts.

A small part of a package.json

{
  "name": "blueticket-app",
  "dependencies": {
    "date-fns": "^3.6.0",
    "qrcode": "^1.5.3",
    "zod": "^3.23.8"
  }
}

npm install reads this list and downloads each package, plus everything those packages depend on.

In a JavaScript project, the list of dependencies lives in a file called package.json. When Anna ran npm install, npm read that list, downloaded every package (and their dependencies) from the registry, and put them in node_modules. That folder is never written by hand and never saved in Git — anyone can recreate it with one command.

Reusing code is a huge win, but it has costs. Every dependency is code you didn't write and must trust. It can have bugs, security holes (Act 22) or be abandoned by its author. Good teams add dependencies carefully and keep them updated — something Anna will deal with in Act 16.

Key Takeaway

Most software is built from reused code. You call a library; a framework calls you. Packages bundle reusable code with a name and version, and a package manager installs them with all their dependencies. An SDK is a full toolkit for a platform, and an API is the agreed way one piece of software talks to another.

Why This Matters

On almost every team you join, most of the code that runs will be dependencies. Knowing how to find, install, update and judge them is a core daily skill. It also matters for safety: in Act 22, a single outdated dependency becomes one of BlueTicket's security problems, and the fix starts with understanding exactly what these packages are.

Anna understands what she installed. One last question from today: when she ran npm run dev, a program started, kept running, and stopped when she pressed Ctrl+C. What actually happens inside the computer when a program starts, runs and ends?