Could Worker Threads speed up common Node.js applications in 2019?

You should avoid blocking the Node.js main event loop thread with CPU intensive work to maintain the high levels of request throughput that Node.js is otherwise capable of achieving. Also, expensive processing must be spread to multiple threads to properly utilize the power of modern CPUs, including those available in the virtual server instances of popular cloud environments.

Ever since the Node v10.5.0 release, Worker Threads have been available in the standard library. They can be used to execute expensive Javascript processing without blocking the main event loop thread, and for utilizing multiple CPU cores. However, the scenarios in which they can provide a performance benefit are somewhat more restricted than threading in some other high-performance languages.

Objection to ORM hatred

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”. I completely understand where the hatred comes from. There are real problems in many ORMs, that Thomas Hunter II summarizes well in his post Why you should avoid ORMs.

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.