The fallacy here is the assumption that we get "hammers" as libraries, and not some splinters of wood in one crate and a whole bunch of hammer heads in another.
A "hammer" is useable on its own, it's a self-sufficient object of value. The "libraries over frameworks" mindset as practiced leads to splitting libraries by underlying technical concerns, not practical utility. There is no practical utility in a "routing library" or an "ORM library"; there is a lot of utility in a "login system", but realistically a login system has a lot of cross-cutting concerns, from database access to sessions to forms to templating.
Instead what we get is a wide selection of hammer heads and handles, all requiring assembly and not quite fitting to each other.
A "hammer" is useable on its own, it's a self-sufficient object of value. The "libraries over frameworks" mindset as practiced leads to splitting libraries by underlying technical concerns, not practical utility. There is no practical utility in a "routing library" or an "ORM library"; there is a lot of utility in a "login system", but realistically a login system has a lot of cross-cutting concerns, from database access to sessions to forms to templating.
Instead what we get is a wide selection of hammer heads and handles, all requiring assembly and not quite fitting to each other.