Personally I have no real objections to JavaScript as a language but somehow I get the feeling that, in many situations, NodeJS is more a problem than a solutio

Personally I have no real objections to JavaScript as a language but somehow I get the feeling that, in many situations, NodeJS is more a problem than a solution. I.e. JavaScript and NodeJS are two different things and I think they shouldn't be treated as the same thing (i.e. NodeJS is JavaScript and vica versa). NodeJS could have been shipped with a different language (Lua?) but I guess NodeJS surfaced around the same time Google released their V8 engine, so... To me it seems that NodeJS solves a very specific problem; handling many simultaneous persistent network connections (i.e. websockets). I can't help thinking of NodeJS as fundamentally being a programmable socket server. I.e. its purpose is to solve a network problem, not a business logic problem. The problem for me, when I work on large(r) apps that run in NodeJS, is that there is a certain "mental overhead" associated with it. NodeJS has this non-blocking IO, event driven architecture for a very specific reason which makes total sense when you solve IO problems (such as handling many simultaneous network connections) but this behaviour somehow seems to trickle down into business logic. With NodeJS I find myself writing non-blocking, event driven business logic because the environment in which my code runs dictates this. Somehow that doesn't make sense to me. To me business logic is inherently synchronous. Now there are some really clever ways to compensate for this such as the Promise and with never versions of JavaScript there are even new language features to help battle what was originally known as the "callback soup". However, no matter how clever and admirable each of these features are, to me they seem to compensate for a fundamental problem in the run-time environment (NodeJS) that actually makes it not really suitable for anything CRUD and beyond.