bibliothek

Library

In short: A collection of ready-made code (functions, classes) that can be included in your own programs, instead of writing common functionality from scratch yourself.

In more detail: Unlike a framework, which dictates the structure of your own application, a library is actively called from your own code — control stays with the developer. Examples range from small helper libraries to extensive packages for maths, networking or UI.

In Depth

The difference between a library and a framework is often explained with the “inversion of control” principle: with a library, your own code calls the library functions (“I call you”), with a framework, the framework calls your own code (“you call me”, e.g. when a web framework calls the matching handler function for an incoming request). A library can therefore usually be plugged into existing code selectively, while a framework determines the basic structure of the project from the start.

Libraries are usually installed and managed via a package manager, rather than downloaded manually — for JavaScript/Node.js, for example, via npm:

npm install lodash

After that, the library can be imported and used directly in your own code. Good libraries solve exactly one problem well (e.g. date handling, HTTP requests) and can be combined freely with other libraries — that’s their central advantage over monolithic frameworks, which often bring their own solution for many things.

Statically vs. dynamically linked

Technically, a distinction is made in WHEN a library is linked with your own program. With static linking, the library code is copied directly into the finished executable (larger file, but no external dependencies at runtime). With dynamic linking (e.g. .dll files on Windows, .so on Linux), the library remains a separate file, only loaded when the program starts — several programs can share the same dynamic library in memory, which saves space, but also means a missing or wrong version of the library can crash the program (“DLL hell”).

Dependency hell and version conflicts

The more libraries a project includes, the more complex the dependency tree becomes: library A needs version 2 of library C, but library B needs version 3 — a classic problem modern package managers (npm, pip, Maven) try to get under control with lock files (package-lock.json, poetry.lock) and sometimes isolated dependency trees per project (instead of global installation). Security vulnerabilities in widely used libraries (such as the log4j vulnerability in 2021) also show how heavily modern software depends on third-party code — a single flawed package can affect thousands of applications at once.

Library, framework and package — distinguishing the terms

In practice, the terms are often used loosely: a “package” is usually simply the distribution form (what the package manager installs) and can contain either a library or a framework. A framework differs from a pure library in that it prescribes the application’s basic architecture (see inversion of control above) — React, for example, is often called a library because it can be plugged into existing pages selectively, while Angular, as a complete framework, determines the entire project structure.