There is some truth to what the author is saying. Frameworks do tend to be opinionated, and they will tell you to write your code in a particular fashion to pla

There is some truth to what the author is saying. Frameworks do tend to be opinionated, and they will tell you to write your code in a particular fashion to play nicely with the rest of the kids in the framework's playground. However, I think there's more here that the author skirts around. He laments the fact that "in-fashion" changes to a framework force you to refactor your code. I'm not so sure that this is purely a negative thing. Let's take the upcoming Laravel 5 as an example; on the face of it, Laravel 5 is a drastic departure from Laravel 4.2. The directory structure is completely different, and the way you interact with The System is changing in a subtle but significant way (middleware). Is this cause for consternation? Perhaps. It requires developer time to upgrade, which is not free. But the gain is twofold: you benefit from using newer and, ostensibly better, structure around your app; and you grow as a developer, because you learn a new way to do something familiar. I'm not saying here that the author's assertion that this is unnecessary is incorrect; just that there are benefits to being forced into change. Also, regarding libraries: just because two libraries deal with the same topic or technology does NOT guarantee that they'll make the same assumptions about abstraction. Even on the device driver level, you can't take that for granted.