There is a common problem - some fundamental technical problem is complex and has a steep learning curve. In comes the ORM or Library or Plugin or ... These thi

There is a common problem - some fundamental technical problem is complex and has a steep learning curve. In comes the ORM or Library or Plugin or ... These things are all layers on top of the fundamental technology that simplifies the underlying thin. Or that provides a layer that hides the complexity of multiple implementations of a technology. So you adopt it. And you get running. Then you run into a problem with the layer. It does not implement a fundamental part. Or it has a bug, or the implementation you need is not covered. At this point you try to fix the ORM or adapt to it or fix it or something. Because you still don't know the underlying technology. I'm not saying this is a mistake. Sometimes the ORM works and sometimes it does not. It depends on how fundamental this technology is to your product and a host of other issues. BUT! It is always worthwhile to learn and understand the fundamental technology. SQL is not that hard. It is worth understanding. Even if you want and can use and ORM, not knowing SQL will hurt you. And knowing an ORM is just an extra thing to learn. I actually like SQL. I find it hard, a different way to think, but fun. I use React a lot. It helps except when it doesn't - and then being able to work in html, css and POJ saves the day. Even though I never code in assembly language (ever!) knowing how registers, CPU's and instructions work makes me a better coder. So when faced with the choice of a simpler way to do something that provides a layer over a fundamental technology, I am now extremely skeptical. Sometimes it works out, but most often it is not a good choice for me.