This article does not seem well thought out. It takes a condescending look on frameworks (and object-oriented programming) and contains many inaccuracies. For e

This article does not seem well thought out. It takes a condescending look on frameworks (and object-oriented programming) and contains many inaccuracies. For example, most ORM frameworks/libraries allow the developers to map an existing database schema with existing classes. They do not "force" you to follow only one type of mapping. Now, what's the difference between a library and a framework? Hint: it's probably a continuum between no inversion of control and total inversion of control (not "reversion of control" btw). Many libraries provide some inversion of control mechanisms and "force" you to work their way (tyranny!!!). Is JQuery a library with all its callbacks and the use of $? Should you use JQuery then or "stay in control"? As for: "So, our advice to you is to stay in control of the development path of your software and prefer libraries over frameworks for real-world projects." Where is the nuance, the "it depends" in this conclusion? It depends on where you are in the product lifecycle, where your competitors are, how many developers you have, what your core features are vs. what features the frameworks can provide, etc. For example, imagine that you invented a new programming language. Say clojure. Now you want to provide syntax highlighting, syntax checking, tab-completion, features that an IDE provide. Will you (1) write a completely new IDE or (2) write a plug-in/extension/script for vim/emacs/eclipse/netbeans? Are they, "real world projects"?