[ragnese]

I think there's a problem of what we actually mean when we call something a "framework." Is an ORM a "framework" for interfacing with persistent data stores (usually SQL databases)? Common parlance says it is--and I tend to agree--but, it's also "just" a library to get in between your app and your data, which feels different than, say, a web framework that dictates how your whole project is structured, what auth methods are "supported", what interfaces your handler code is allowed to implement, etc.

But, I also I think your sentiment is somewhere between a generally wise piece of advice/wisdom and a vacuously true statement of fact. The latter because of course you should not reinvent the wheel if there's a perfectly fine wheel already out there.

Frankly, a lot of these things we call frameworks are actually fairly low quality. And I say that with the humility of knowing I couldn't do any better, but that doesn't make it less true. One of my "favorites" to shit on is the Java ecosystem. In particular, JDBC/Hibernate for ORM/SQL stuff, and JacksonXML for (de)serialization. Both are absolutely awful for various reasons, but my go-to example is that JDBC literally doesn't have an API for getting a nullable integer column value out of a ResultSet; instead, you have to get a non-nullable int primitive which will be `0` if the database value was `NULL`, THEN you have to call a second method to ask "Was the previously returned value from this ResultSet actually a NULL instead of whatever I got?". This manifests in Hibernate as requiring an easy-to-forget-or-misuse annotation on your DTO class.

My point is that some of these frameworks are a total nightmare for reliability and robustness, and I'm not convinced that just reflexively opting in to all of the "de facto" frameworks at the beginning of a software project is always the right move.