>Libraries aren't everything, but they should be preferred.
The story is much much more complicated than this. Every single one of you is using a framework everyday, that is unless you program in assembly language.
All Programming languages are highly opinionated frameworks on top of assembly languages.
When you know this, then you know that you can't just say something simplistic like libraries are "preferred."
If all programming languages are frameworks on top of assembly language then frameworks are not only preferred they are Required for humans to make sense of complexity.
When you write a framework like django within the framework of python you are putting a framework within a framework. It's similar to writing a compiler that compiles some PL into python. You are building layers and layers of interfaces between your logic.
For every extra layer you add, two things, in general, happen:
1. Complexity decreases
2. Restriction increases
So when someone writes an article like this, what they are actually saying is this:
"The complexity and restriction balance in the current framework/programming language
strikes the right balance so in my opinion (keyword)
writing another framework on top of the current framework will
increase the restriction to the point where the trade off is not worth it."
When writing a library as opposed to a framework, what people are essentially doing is augmenting the capabilities of the current framework without creating an extra layer of abstraction. Another good way to think about it is that frameworks are equivalent to extra layers of abstraction and therefore the benefits and downsides of adding more layers of abstraction are equivalent to adding more frameworks. So it's really not as simple to say that "Libraries are preferred."
The story actually gets even more complicated then this. I spoke previously as if there is a trade off between Complexity and Restriction. While a decrease in complexity is always good, an increase in restriction is not always bad.
Take for example ELM. ELM is a language (or framework) that compiles to javascript and HTML. It is more restrictive then javascript due to type checking. Yes type checking is a framework that decreases freedom and increases restriction. But people think type checking is a good thing. Why? Well, the ELM type checker/framework is so powerful that it restricts you from ever writing a run time error. You absolutely do not have the freedom to write code that has certain bugs in ELM while in javascript you absolutely have the freedom to pollute your code with thousands of obscure bugs.
Restriction can be good, really good. In fact restriction outside of testing is our greatest tool and weapon for combating the problem of bugs occurring as a result of too much complexity.
In short, I don't like this article because it doesn't illustrate the full story. It kind of biases against frameworks. The author did not think deeply enough, he thinks of frameworks in terms of things like rails or django, but he does not think of what a framework is from a more general perspective.
Keep in mind, react or how react is used is basically a framework as well. Nobody uses it as a library, they prefer the component abstraction to take over the entire notion of the DOM.
The story is much much more complicated than this. Every single one of you is using a framework everyday, that is unless you program in assembly language.
All Programming languages are highly opinionated frameworks on top of assembly languages.
When you know this, then you know that you can't just say something simplistic like libraries are "preferred."
If all programming languages are frameworks on top of assembly language then frameworks are not only preferred they are Required for humans to make sense of complexity.
When you write a framework like django within the framework of python you are putting a framework within a framework. It's similar to writing a compiler that compiles some PL into python. You are building layers and layers of interfaces between your logic.
For every extra layer you add, two things, in general, happen:
So when someone writes an article like this, what they are actually saying is this: When writing a library as opposed to a framework, what people are essentially doing is augmenting the capabilities of the current framework without creating an extra layer of abstraction. Another good way to think about it is that frameworks are equivalent to extra layers of abstraction and therefore the benefits and downsides of adding more layers of abstraction are equivalent to adding more frameworks. So it's really not as simple to say that "Libraries are preferred."The story actually gets even more complicated then this. I spoke previously as if there is a trade off between Complexity and Restriction. While a decrease in complexity is always good, an increase in restriction is not always bad.
Take for example ELM. ELM is a language (or framework) that compiles to javascript and HTML. It is more restrictive then javascript due to type checking. Yes type checking is a framework that decreases freedom and increases restriction. But people think type checking is a good thing. Why? Well, the ELM type checker/framework is so powerful that it restricts you from ever writing a run time error. You absolutely do not have the freedom to write code that has certain bugs in ELM while in javascript you absolutely have the freedom to pollute your code with thousands of obscure bugs.
Restriction can be good, really good. In fact restriction outside of testing is our greatest tool and weapon for combating the problem of bugs occurring as a result of too much complexity.
In short, I don't like this article because it doesn't illustrate the full story. It kind of biases against frameworks. The author did not think deeply enough, he thinks of frameworks in terms of things like rails or django, but he does not think of what a framework is from a more general perspective.
Keep in mind, react or how react is used is basically a framework as well. Nobody uses it as a library, they prefer the component abstraction to take over the entire notion of the DOM.