It's a bit tough to say because these words are not well-defined. In common parlance, I think it's a bit atypical to call Node.js a framework, sure, but I'd have a hard time arguing as to why exactly it is not.
This all gets dicey, and I often see really poor uses of language, so I'll be explicit and start from the bottom
Now, let's dig into execution semantics a bit. Generally, execution semantics involves a process of reading language text and arriving at either a description of an abstract machine or a description of observable side effects. What I'd like to suggest is that both of these assume the need for there to be some kind of "low-level API" either to operate the machine or to perform the observable effects. These are usually considered to be part of the runtime environment
- The runtime environment or runtime is a set of assumed primitives that the language convention requires to exist in order to operate. As far as the language goes, there may be some assumption about their behavior, but they are unobservable. In the imagery of the interpreter above, the "man inside" just flicks the runtime's switches---he cannot personally inspect what they're doing.
The word runtime is usually abused to mean both the set of assumed primitives themselves and an actual instantiation of them.
So, now we get to something hairy. A language is a set of conventions which assumes the existence of a runtime in order to provide meaning to its execution semantics. It never "probes into them" as they are out of scope.
In order to actually use a language you want something like a compiler or interpreter alongside a runtime implementation. The compiler/interpreter and this runtime go hand in hand in actually executing your code.
So where does Node.js fit into this?
We have to break it into parts:
- Node.js, as a package, contains an interpreter and a compiler. It just steals these from V8.
So Node.js is a lot of things!
But is it a framework?
This is where terminology totally falls apart—nobody has a good, consistent, meaningful definition of what a framework actually is.
In my personal opinion, there is something substantial here. I don't want to draw a bright line, but so I'll merely say
- A set of code is library-like if it works like a set of legos: divisible and made for assembly. While there might be some examples for how to use the library, it is generally on the user themselves to assemble it toward their needs.
- A set of code is framework-like if it is non-divisible and implies conventions*: pulling pieces of it apart can cause many assumptions to fail so you have to understand conventional use in order to use a framework properly.
This is a hand-wavey line to be sure, but I want to draw out a really interesting point about frameworks:
Frameworks imply a set of conventions of how to interpret code; they are therefore a language in their own right.
This might be something that people want to argue about as well, but if you bought my earlier definition that a language is just a set of conventions which give life to a block of text, then whenever you lay down a new layer of conventions you've built a new language. Perhaps with frameworks the raw materials are the semantic interpretations of their host language instead of raw text files, but the idea is the same!
I would argue that if at this moment you feel a bit queasy and want to argue that there's a huge divide between Ruby on Rails and Node.js in this way of things then I'm right there with you, of course. The kind of conceptual worlds that the two live in are dramatically different—I merely want to say that they're the same kind of thing: sets of conventions for expanding the powers of a base language within a particular domain.
I'm also happy to suggest that Node.js's domain is tiny and tight and thus the conventions it adds are simple to reason about and relatively easy to make correct. OTOH, Ruby on Rails lives in a complex, poorly defined domain of "business web applications" which means that the conventions it lays are certainly fuzzy and broken.
But all of this is a long way of saying, yeah, recruiters probably have no idea what they mean when the say that. I'm guessing "framework" just sounds like a better, more grokkable word than "runtime" or "engine".