Borrowing code instead of writing it
Imagine needing to sort dates, send an email, or resize a photo. You could write that logic yourself, but someone has almost certainly solved the problem already, tested it, and shared it. Libraries are how that shared work reaches you. You pull one into your project, call the pieces you need, and carry on with your own design. Your code stays in charge: it decides when to call the library and what to do with the result.
Most languages ship with a standard library (Python's math, json, and datetime; Java's java.util), and far more are available from the community as installable add-ons.
Calling a library function
Python's standard library includes a statistics module. Nothing extra needs installing:
import statistics
scores = [72, 88, 95, 61, 80]
print(statistics.mean(scores)) # 79.2
print(statistics.median(scores)) # 80
You chose when to compute the average and what to print. The library just did the arithmetic.
Library vs framework
The usual way to tell these apart is to ask who calls whom. With a library, your program calls the library. With a framework, the framework calls your code: you fill in pieces (a route handler, a controller, a component) and the framework decides when they run. People call this "inversion of control."
Real tools don't always fit neatly on one side. Some projects market themselves as libraries while still calling your code on their own schedule, so treat the distinction as a rough guide rather than a strict rule.
Libraries are usually distributed as a package, and once your project relies on one it becomes a dependency worth keeping track of.
Learn more
Last updated