Typically, I think of a framework as something that calls your code, where a library is code that you call. The line gets blurry, of course, because just about

Typically, I think of a framework as something that calls your code, where a library is code that you call. The line gets blurry, of course, because just about any framework is going to include some libraries, and you may use some libraries by registering callbacks. But, something that gives you a bunch of blanks to fill in with your code would be a framework. Now, some frameworks include a set of libraries for the most common tasks you'd want to do when using that framework. E.g., a web framework that provides some sort of ORM. Usually, you can substitute other libraries for those purposes, but doing so has some cost (you feel like you're "fighting the framework", or, you need to deal with configuration overhead for those libraries you're not using). Ruby on Rails is an example of this. This is what I think the grandparent meant by "monolithic framework". Other frameworks have a more narrow focus and expect you to select and provide libraries for common tasks. Ramaze (an alternative Ruby web framework) is an example of this. Obviously, the line can get blurry, but most frameworks do seem to have a philosophy of "provide everything a developer needs to get started" or "allow developers to choose the most appropriate tools".