Difference between a module, library and a framework

In popular programming speak, what is the difference between these terms and what are the overlaps?

Any related terms I'm missing out?

All three of those provide functionality.

However, there are important differences.

A library is just a collection of related functionality. Nothing more, but also nothing less. The defining characteristic of a library is that you are in control, you call the library.

The defining characteristic of a framework is Inversion of Control. The framework calls you, not the other way round. (This is known as the Hollywood Principle: "Don't call us, we'll call you.") The framework is in control. The flow of control and the flow of data is managed by the framework.

You can think of it this way: in both cases, you have an application, and this application has holes in it, where code has been left out, and these holes need to be filled in. The difference between a library and a framework is

• who writes the application,
• what are the holes and
• who fills in the holes.

With a library, you write the application, and you leave out the boring details, which gets filled in by a library.

With a framework, the framework writer writes the application, and leaves out the interesting details, which you fill in.

This can be a little confusing at times, because the framework itself might also contain boring details, that the framework author filled in with libraries, the parts that you write might contain boring details, that you fill in with libraries, and the framework might provide a set of bundled libraries that either work well with the framework or that are often needed in conjunction with the framework. For example, you might use an XML generator library when writing a web application using a web framework, and that XML library might have been provided by the framework or even be an integral part of it.

That doesn't mean, however, that there is no distinction between a library and a framework. The distinction is very clear: Inversion of Control is what it's all about.

The defining characteristic of a module is information hiding. A module has an interface, which explicitly, but abstractly specifies both the functionality it provides as well as the functionality it depends on. (Often called the exported and imported functionality.) This interface has an implementation (or multiple implementations, actually), which, from the user of a module are a black box.

Also, a library is a collection of related functionality, whereas a module only provides a single piece of functionality. Which means that, if you have a system with both modules and libraries, a library will typically contain multiple modules. For example, you might have a collections library which contains a List module, a Set module and a Map module.

While you can certainly write modules without a module system, ideally you want your modules to be separately compilable (for languages and execution environments where that notion even makes sense), separately deployable, and you want module composition to be safe (i.e. composing modules should either work or trigger an error before runtime, but never lead to an runtime error or unexpected behavior). For this, you need a module system, like Racket's units, Standard ML's modules and functors or Newspeak's top-level classes.

So, let's recap:

• library: collection of related functionality
• framework: Inversion of Control
• module: abstract interface with explicit exports and imports, implementation and interface are separate, there may be multiple implementations and the implementation is hidden

You can see a module, a library and a framework this way:

• module = your fingers
• library = your hands
• framework = your body

Your fingers / Module:
You can move them, touch things, you have 5 in a hand so you can use them to hold things in an easier way, those are not the biggest parts of the body but are one of the most useful parts, without them you couldnt hack!... modules are part of a program, you can use them, expand code to other files (not a large file with a lot of code in it), they make the reading easier.

Your hands / Library:
Hands are a set of 5 fingers each one, you can hold things, move things, interact with them, etc... libraries are part of a program too! and they can be seen like a set of modules, you can use them to interact with other programs or make relevant things with your program.

Your body / Framework:
Your body is a complete system, you can do with your body whatever you want (even fly, just walk into a plane and there you go, a plane is another system), you are unique... a framework is your body, a complete system, it doesnt work for itself (you need to code herpderp) but you can make a complete program with some hacking runs...

> just my interpretation... if im wrong please fix ME.

My ASCII art interpretation of what I understood from other answers:

+-----------------------------------------------+
|  ...........................  ..............  |
|  : f1() f2()  :  f3()      :  : f4() f5()  :  |
|  :            :            :  :            :  |
|  : l1_module1 : l1_module2 :  : l2_module3 :  |
|  :            :            :  :            :  |
|  --library1-----------------  --library2----  |
|                                               |
|   application.c                               |
|                                               |
|       #include l1_module2                     |
|       #include l2_module3                     |
|                                               |
|       int main() {                            |
|           # case 'reload'                     |
|           f5();                               |
|           # case 'start'                      |
|           f1();                               |
|           # case 'stop'                       |
|           f4();                               |
|       }                                       |
|                                               |
+-----------------------------------------------+

.................................................
: FRAMEWORK_X                                   :
:                                               :
:     application start                         :
:     ...                                       :
:     application reload                        :
:     application stop                          :
:     ...                                       :
:...............................................:

What happens:

1. Developer installs library1 and library2 so that they can use functions provided inside modules of these.

2. They then include l1_module1 and l2_module3. (They do not need l1_module2 for now).

3. Now they can use the functionality of f1, f2, f4 and f5, So they write their application.

4. Now, since they want to use the application inside some FRAMEWORK_X, they must implement the interface that this framework needs: so that the framework can call the application.

Some notes:

• In practice, there is always some framework. For example, the OS is framework for your application (which is why you define main())! Or you could say that the bootloader is framework for your OS and the BIOS is framework for your bootloader etc.

Package vs Module vs Library vs Framework:

1. Package - Collection of classes/files of similar functionality.

2. Module -It is the smallest piece of software. It is set of methods/functions ready to be used somewhere else.

3. Library - It is a collections of packages. It offer a set of functionalities ready to use without worrying about the how it has been written. All we bother about is input/output.

4. Framework - It's a set of libraries. along with functionalities, it also provides an architecture design or wire frame. It offers well designed patterns to your project. we don't include a framework. we integrate our code into it.

Roughly, I'd consider it this way: a module is an importable "atom" of functionality; it defines the smallest subset of grouped functionality that can be used (note that it's not the smallest unit of functionality; that would be a class (or function, depending)). A library would be, in this approach, a set of modules; you can use a library without using all of the modules that are part of that library. A framework is the environment upon which the library (likely) depends; it makes up the baseline environment within which all of the above work.

Note that these terms are somewhat fungible, and these definitions will not always be solid in every situation; this is just my interpretation of some of the common usages I've come across.

I believe frameworks and libraries are modules. Since modules are codes imported or exported from your code. As they say, Frameworks calls your code, your code calls libraries. Either way, a module is involved

From my point of view a framework contains libraries and both are modules.

E.g. In Swift a module is a single unit of code distribution — a framework or application that is built and shipped as a single unit.

In my opinion a module could be a subset of a library, which in turn could be a subset of a framework. But I'm sure there are exceptions to this and various interpretations based on the context -- especially for the term module.

Module

A module is the output of modular design, a component with various granularity.

In context of modular programming, a module is an entity expressible by the coding language introducing the programmability (typically, a programming language or a hardware description language) to the solution.

Some languages explicitly support the concept of module and provide it as a language feature. A notable early instance is Modular-2. Despite the feature, users can still specify other kinds of modules by conventions with different granularity in software design and project management, like a source file and a directory of source files. The built-in language feature does not eliminate the need of modules of different granularity, but people may use different terminology to avoid possible ambiguity with the language feature.

Some other languages do not provide specific feature named module, but users can make choices to specify parts of program as modules. For example, the C language does not have modules, but users can specify a function, a source file, a translation unit (a source file with the headers it includes) or even bunch of files as a module on demand. A module in such case can be with different forms of code: source, binary code from source or provided elsewhere with linkage compatibility guarantees, or even mixed.

The only real restriction of "module", if any, is that it should reflect to the result of some modular design, so components in a module should share some similarities to make the boundary clear. A module should usually provide some kinds of exported interface to users; it may optionally import dependencies from external program components. Some of modules can be a submodule of others.

Code management tools may utilizes the concepts related to module. For example, Git has the concept of submodule, which is essentially a versioned subdirectory of code in the repository.

Library

A library is a specialized kind of program module containing (more specifically, owning) a collection of (sub)modules to be used in some encapsulated (that is, not allowed being modified directly in later use) manner. Usually a library is designed to be reused and deployed within non-volatile storage. Typically, a library is provided as one or several on-disk files in some steady persistent formats. Such libraries are called archives, dynamic objects, packages, etc. With support of external program databases, libraries can also be identified by means other than filenames or other file-based properties. For example, CLI provides library assemblies with aid of GAC.

Framework

A framework is another specialized kind of program module which contains various pre-desinged functionality of code. A framework can be deployed in a form of one or several libraries. The difference between a framework and other kinds of modules in a program is that the former emphasizes a mostly complete, freezed but adaptive and extensible solution of some common work, so the user of the framework can focus on the domain-specific and project-specific problems instead of writing glue code to put different libraries together and to make them work fluently. However, this has a cost of design complexity throughout the whole project. Notably, many (but not all) frameworks would enforce users' code following an IoC style. As a result, it is almost impossible to put same kind but different frameworks together smoothly in an idiomatic and natural way. Using language with first-class control effects, IoC is not explicitly required in a framework. However this implies that combination of normal libraries to having functionality of a framework is easier to achieve, so there is less need to organize program modules like traditional frameworks which often undermine flexibility easily.

Library: A collection of namespaced/modularized code.

Framework: A framework is some piece of code (wheter it’s a compiler, a design pattern or something else) that is reusable and thereby makes life easier for developers so that they do not have to reinvent the wheel.

Module: In JavaScript for example a module is just an object with public properties. I'm not sure, but I think there is no generic answer for the term Module.

HERE IS A SHORT DESCRIPTION

What is a Module?

This could be different based on context, but I believe a module is generally just a part of a library, as it contains many tools that are equally useful for the developer (see library explanation below).

What is a Library?

A library is a collection of code blocks (could be in the form of variables, functions, classes, interfaces etc.) that are built by developers to ease the process of software development for other developers that find its relevance.

What is a Framework?

With reference to the definition of a library, we could define a framework as a tool that helps a developer solve a large range of domain-specific problems by providing the developer with necessary libraries in a controlled development environment.