Earlier quoted context omitted.
The usual heuristic I've encountered is that a library is something where your app code uses it and asks it to do things, and a framework is something where your app code hands off top level control and the framework asks your app code to do things. Whatever you think of that terminology, I think the majority of available things you can use do fall substantialy into one or other of those categories and the difference…
> Whatever you think of that terminology, I think the majority of available things you can use do fall substantialy into one or other of those categories and the difference in working style while using them is a distinction worth being aware of. I think that the offered terminology is nicely put and should be good enough to describe most cases! However, what we might find is that either it's more of a spectrum than a…
But yes, it's not completely binary, hence my saying 'most' a lot - the library/framework distinction definitely has a wide and fuzzy boundary line ala the time years (decades?) of disputes happened because somebody drew a negotiated official border with a really blunt pencil - but I'm advocating the idea that the distinction is a useful way to carve reality at the joints in a sense of "all models are wrong; some models are useful."
Plus, I mean, the 'is it inside' thing would make PSGI/WSGI/Rack/etc. count as a framework since generally they call your application, but they're not really framework-y in spirit on their own (middleware starts to get fuzzier, of course, but I think we're agreed that 'fuzzier' is an inevitably recurring theme here)