For me, ORMs and [web] frameworks serve essentially the same purpose - Establishing some development pattern that can be followed.
Most developers do not feel comfortable jumping directly into raw sql/js/html/css when they are just starting out in their careers, especially when trying to build a new/complex thing. Having effectively zero constraints on how to structure a real-world codebase can be terrifying if you don't have an existing mental model of one of these things. I remember what it was like to be staring into the maw of a blank solution explorer and not even knowing how many projects I would need to create or what a good namespace system might look like.
Understanding that the sql schema is probably the most important part of the entire product may encourage us to not sweep this particular concern under the rug of automagic training wheels. We did the entity framework thing for about a year before moving back to raw sql. Performance was the biggest thing for us. Many of the inferences the ORM made back then were horrific in practice.
Seems like a lot of similar ideas! Database-first, typesafety, code generation. Though ultimately SQL has some core incompatibilies with object-orintation, and the active record pattern has some fundamental issues that Neward touches on in his power. Though there's not really any other option in Java.
There is that deep problem that there are three ways to represent inheritance relationships in SQL and they are all flawed.
Other than that though my feeling is that ORM implementations have improved dramatically in all languages if only because of hard experience. I don't think it is like the Vietnam war anymore.
You get in trouble with ORM if you thing that "object is greater than relational" not because one is better than the other but because when relational is persistent and object is transitory, relational is the "real" thing and the objects are an abstraction of the real thing.
Jooq turns it around by being a "relational-object mapper" that lets you write relational queries in a Java DSL that plays really well with the autocomplete features of your IDE. I think it compares favorably to what Microsoft tried to do with LINQ.
Most developers do not feel comfortable jumping directly into raw sql/js/html/css when they are just starting out in their careers, especially when trying to build a new/complex thing. Having effectively zero constraints on how to structure a real-world codebase can be terrifying if you don't have an existing mental model of one of these things. I remember what it was like to be staring into the maw of a blank solution explorer and not even knowing how many projects I would need to create or what a good namespace system might look like.
Understanding that the sql schema is probably the most important part of the entire product may encourage us to not sweep this particular concern under the rug of automagic training wheels. We did the entity framework thing for about a year before moving back to raw sql. Performance was the biggest thing for us. Many of the inferences the ORM made back then were horrific in practice.