I think the dichotomy between frameworks and libraries appears from the observation that both concepts are good at what they do when they are designed with the opposite principle in mind, to which they are implemented themselves.

In programming, everything sits between two poles.

Pure and impure, centralized and distributed, limiting and freeing.

Without limits, there is no experience of freedom.

Keeping you in line on the highway will ensure your freedom to move on it.

Limits are not always limiting, and a lot of freedom can be confusing as heck.

As Clojure and C++ developers ;)

The same I observe around libraries and frameworks.

I used to think as the linked article describes it (and there is a lot of truth to it)

And I think I found a couple of other layers to it.

Libraries let you call them and frameworks call you.

Libraries are imported by you, and that means you are in charge.

Frameworks are the opposite: They "import" you, and you do as they desire.

They are restrictive and style your code.

Frameworks dictate how you code - libraries deliver to you, what and when you need it.

The issue is, that libraries are the best, if they are as limited in scope as possible, and frameworks are best when they are the opposite.

I think that is, what confuses most people about it:

Frameworks introduce a certain coding style and dictate the way things are implemented.

But that doesn't mean, it has to be limiting.

The Node system in Godot allows you to compose your actions very freely, allowed by using composition over inheritance, and certain other decisions.

The implementation of this specific framework allows you to move freely despite that you have simply no other way, besides using it.

You are forced to freedom, basically.

It is limiting, but it is not.

That contradiction is probably, what causes many people to dislike frameworks at all.

They experience mostly bad ones.

A framework can be limiting on HOW you can do things, and this can still result in a lot of flexibility.

A library can offer a lot of things, but this might turn out bad if the consequences are not easy to foresee.

How often did you load a library, that behaved unpredictably, changed its behaviour from one update to the next, or was simply implemented badly?

If all libraries were that way, we would dislike them as well.

That is also where the saying "do one thing, and do it good" fits right in.

It is simply a guide to good library design.

So, when looking at frameworks and libraries, we have to differentiate between the respective way they interact with the rest of the code and the practical effect they bring to our code.

We should not mistake the way they are implemented, with the effect it has on us.

This sounds easy enough, although I think it's tempting to believe, that the face value is always mirroring the inside.

So, all that doesn't take away from the practical limitations, that were raised in the article (and other articles of its kind, see ¹ and ².

So far as I can see, the argument is always down to a 'badly implemented framework, that is not enabling a lot of freedom' and things like a framework simply not being the right choice for the task.

If frameworks are about *consciously* limiting freedom, to grant just that, then it's about the one thing that we can say computing (and life) is all about:

Finding the right tool for the task.

Doesnt sound very spectacular, but considering the vast majority of people to whom I talked about this today, did not even know there is a difference between frameworks and libraries and even less so, which one that is, I feel like it warrants a post.

And a discussion.

¹ https://timperrett.com/2016/11/12/frameworks-are-fundimental...