The Definition of Framework

#frameworkless #javascript

What is a Framework? This is one of the questions that emerged in one issue of the Frameworkless 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

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.

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

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 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.

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 pattern. In 2018 I gave a talk at a conference about this specific topic for frontend applications.

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, HTTP requests 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