The Definition of Framework
Tags: frameworkless, javascript
Published: 2020-07-01 19:38:39

**_What is a Framework?_** This is one of the questions that emerged in one issue of the [Frameworkless](https://github.com/frameworkless-movement/manifesto) Manifesto.
As developers, we all know and use some frameworks in our daily job, but finding a definition of "Framework" is not a trivial task.

## What is a Framework?

To try to answer this question, let's start with a definition taken from a [dictionary](https://dictionary.cambridge.org/it/dizionario/inglese/framework)

> a supporting structure around which something can be built

This is, surprisingly, a _good enough_ explanation. If you think about some famous development framework like Angular or Spring it perfectly matches with this definition. They give to the developer a structure, usually defined as a series of architectural decisions that the team decided to delegate to the Framework. As an example, if your team decided to use Angular it delegated to the Framework some architectural decisions like language (TypeScript) and that your application will be heavily based on the reactive paradigm.

## Libraries

Usually, during the lifespan of a project, we don't use just frameworks, but also other packages that can help us with specific problems like manipulating arrays or dates. In a JavaScript application, your stack may contain `lodash` or `date-fns` or other packages like that. Are these frameworks too?

The answer is _"no"_, following the previous definition. These packages are in fact called _libraries_.

So, what is the difference between Frameworks and Libraries? A quote that I use often to describe them is the following:

> A framework calls your code. Your code calls a library.

![A framework calls your code. Your code calls a library](https://files-i2iz7grtg.now.sh/)

This is an easy way to classify if a package is a framework or a library. As an example, this is a piece of code of a simple function that use `date-fns`

```javascript
import { format } from 'date-fns'

const dates = {
 isMonday: date => format(date, 'i') === 1
}

export default dates
```

As you can see I just call the library inside my JavaScript object. What I created here is a simple [Facade](https://en.wikipedia.org/wiki/Facade_pattern) implementation to hide to the rest of my application the existence of `date-fns`.

What happens if, for whatever reason, I need to change `date-fns` with another library or to remove date libraries completely? I just need to rewrite my Facade object. So, with very small design efforts, libraries are easy to change during time.

On the other hand, this is a simple Angular service, taken from the [tour of heroes](https://angular.io/tutorial/toh-pt4).

```javascript
import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class HeroService {

  constructor() { }

}
```

In this case, trying to remove Angular will result in breaking all of your application. Most of the code written in a framework will lose its value when the framework is removed. Changing a framework in an existing project could be a very long and difficult task. One of the refactoring techniques that you may use is called [Strangler Fig Application](https://martinfowler.com/bliki/StranglerFigApplication.html) pattern. In 2018 I gave a talk at a conference about this specific topic for frontend applications.

{% youtube cTSoFvAUUF8 %}

We can now define a better way to describe the difference between a Framework and a library.

> A library should be easy to change, a Framework (most of the times) is not.

## The Framework's Way

We have a clear definition of Framework and a simple rule to differentiate them from libraries. Problem solved, right? 

After this explanation, it should be easy to answer the question

> *React is a Framework or a Library?*

Alas, is not so simple. The official definition of React, stated in the official website is:

> A JavaScript library for building user interfaces

Ok, so it's a library. Following our previous statement about the difference between Frameworks and Libraries, React should be easy to replace. But removing React from a project is not an easy task. The same thing often happens with another (in)famous "library" like jQuery.

Why are some libraries so hard to change? What do React and jQuery have in common?

When a library becomes _mainstream_, people tend to amplify the library's core concepts to all the part of the applications. The React's mantra _"Everything is a component"_ could lead to writing everything as React Component like [Routes](https://reacttraining.com/react-router/web/guides/quick-start), [HTTP requests](https://github.com/jamesplease/react-request) and other parts.

React has a "way" of doing things, and accepting its way means accepting a lot of rules and decisions that you delegated not to the library itself, but to its "Framework's Way".

This is not a bad thing _per se_, but it's a very important factor to keep in consideration when choosing a technology stack. This leads to my personal and opinionated definition of Framework

> ###When there is a Framework's way, there is a Framework


PS: If you liked this post, you can buy me a virtual coffee ️😊

[![Buy Me A Coffee](https://cdn-images-1.medium.com/max/1600/1*WC5MWSS6s4JmUHjtztIusg.png)](https://www.buymeacoffee.com/strazz)