[mst]

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 in working style while using them is a distinction worth being aware of.

[KronisLV]

> 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 binary library/framework division (e.g. your example of falling mostly into one or the other, even if not wholly), or that things start to depend on how we use certain technologies.

In my experience, Vue, React and Angular, even Svelte would typically all be used as frameworks, even if that's not the mainstream description of them. The "project" with whatever business logic needs to be implemented would be built within those technologies - using their approaches to components, data binding, validations, routing, state management and so on, possibly by integrating additional bits of code with them, where not available out of the box, still typically with one or two idiomatic (popular) packages.

But hey, regardless of the naming/classification aspects they can all be a good choice (as can Nuxt or Next.js, as well as SSR) for at least certain kinds of projects, as long as some inherent drawbacks of the architectures themselves aren't forgotten about.

[mst]

Mmm ... while e.g. in React a lot of state libraries are specialised to React, I've had a fair amount of success using e.g. MobX for state management and React as the view rendering layer it was originally advertised at.

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)