> does not require the dev to implement their own "hooks" into its methods > tell the framework how to work [...] and just send it data in the way it expects

> does not require the dev to implement their own "hooks" into its methods > tell the framework how to work [...] and just send it data in the way it expects What is that, if not also "hooks"? I've long thought about this and tried many different solutions, and there's only 2 sane points to implement a library/framework like this in an unopinionated way IMHO (without prescribing the DB schema, etc): you provide a library like passport.js with lower level hooks (data hashing, vendor connections, etc), or you provide a framework integration with higher level hooks (API, DB schemas, etc); the problem with the higher level hooks is that you'll need many more hooks, with the only advantage that the dev might need to write a bit less code overall. As an example, let's see password recovery. With lower level hooks, the dev writes the recover page fully, the API endpoint and backend for it, and somewhere in this backend has a small integration with the hashing the new password; which then the dev saves in the DB. The dev has to do all of this, but in exchange the hook integration is just "hash the password". However for a higher-level (let's assume a JSON API) integration as you seem to suggest, now you need to use the hooks from the front-end to the custom API, two endpoints that hopefully work as expected. And then you need to use the hooks to connect from the data generation to the DB, again at least 3-4 hooks to check for the valid user, check for duplicated password (maybe?), save the new password. And error handling here and to the front-end, which is going to be a monster. (or an opinionated way like Firebase where you bring the whole house, but let's leave that for another post)