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
JavaScript is a computer language, which is to say, narrowly, a set of conventions which allow us to read and interpret a bunch of text as having execution semantics—a fancy word for "way of interpreting the language as a set of instructions". Classes of programs called interpreters, compilers, transpilers, linters, highlighters, etc. all take text in and attempt to do something with this conventional understanding of how to execute the code.
- Interpreters actually perform the execution semantics by operating some machine—usually your computer. You can think of them as a little man inside your computer flipping switches like "print this character" based on instruction written in your JavaScript program.
- Compilers try to convert the JavaScript text to a new set of text which has execution semantics for a different language—perhaps one with the special property that computers can directly execute it.
- Transpilers are a generalized form of compiler in that they take JavaScript text in and output text of some other language. The difference is thus a little subjective, but usually one thinks of a compiler as outputting very low level code and a transpiler as outputting high level code.
- Linters, highlighters, type checkers, etc. all take in JavaScript text and output some kind of analytical product, highlighted text e.g., which is influenced by the execution semantics, but not actually representative of it.
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.
- Chrome's V8, often called an engine, is a package deal containing an interpreter, compiler, runtime implementation compatible with the runtime interface demanded by the ECMA standard JavaScript conventions.
So where does Node.js fit into this?
We have to break it into parts:
- Node.js expands the JavaScript language by providing a larger set of runtime environment primitives—those which are outside the scope of ECMA's standards. These include things like file I/O. This means that Node.js changes the language and is in some sense a new language: "Node.js JavaScript"
- Node.js, as a package, contains an interpreter and a compiler. It just steals these from V8.
- Node.js provides an implementation of the Node.js runtime environment which allows "Node.js JavaScript" to be executed.
- Node.js provides a set of standard libraries built atop the new primitives which make them more accessible to end users of "Node.js JavaScript".
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.
There are debates that rage: "what is a framework versus a library" and they end on unsatisfactory things like "a library is something you call and a framework is something that calls you". I don't even really want to give such a sad explanation the light of day—but JavaScript, and Node.js JavaScript in particular, is an enormous blow to this definition since the whole callback-passing technique means you are constantly switching between calling and being called.
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!
So with all that said, I'm totally happy to call Node.js a framework even if it goes a bit against the norm! Node.js adds functionality to raw JavaScript in the way of expanding the language. With it brings new assumptions and tools for working in this expanded language. Functionally, these ideas are the same as the ideas of other well-accepted frameworks like Ruby on Rails.
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".
