Whenever someone asks which Node.js ORM they should use, one of the first answers is always some version of “don’t use an ORM, just write SQL”. This answer is then usually attacked with an opposite opinion along the lines of “you need to use an ORM to hide all that nasty SQL”. People always seem to ignore the third option: using an ORM that embraces SQL!

I completely understand where the hatred comes from though. There are real problems in many ORMs, that Thomas Hunter II summarizes well in his post Why you should avoid ORMs. The main points Thomas listed were

You learn the ORM, not SQL and that knowledge is usually not transferable to other tools. Complex ORM calls are inefficient. ORMs have their own object-oriented query language which they try to convert to SQL, and it’s usually really difficult. ORMs can’t do everything. The object oriented approach of most ORMs doesn’t map well to SQL. For many SQL operations, there is no object oriented equivalent.

These problems arise from the fact that most ORMs are designed to abstract away SQL in favor of some object oriented interface. But not all ORMs are like that!

I created an ORM called objection.js for exactly the reasons Thomas listed. The design goal of objection.js is to allow you to use SQL whenever possible and only provide a DSL (Domain Specific Language) or a custom concept when something cannot be easily done using SQL. I’ll get back to objection.js soon. First, I’ll introduce you to the most common argument for avoiding ORMs:

It’s easier to write <something> in plain SQL than using an ORM

This argument is usually followed by a contrived example like this: