I agree with the sentiment of the of the article. Dependencies should be isolated and not spread out all across your application. Even though both don't have ti

I agree with the sentiment of the of the article. Dependencies should be isolated and not spread out all across your application. Even though both don't have tight definition, I think it's fair to say that a framework is usually larger in scope and API surface area than a library and usually impose a certain way of coding (and toolchain) on you. Isolating your dependencies (gui, persistence, ...) is a lot easier when you use a small library than using a framework that pretends to have all the answers. It is true that you have to lay out more infrastructure yourself working this way but I feel that this is a really good thing because it makes you really think about the problem you are trying to solve, and don't just think in terms of the patterns your framework offers (e.g. MVC: "I have some logic, so I'll put it into a controller!"). This usually leads to code that is a lot easier to understand and is easier to test. Also, every application is different and with the framework way of doing will always end up having to shoe-horn things.