I keep seeing recruiters, developers, etc. refer to Node.js as a framework. In my opinion, this is out of ignorance for what Node.js really is.

Oftentimes, in job descriptions, Node.js is grouped in as a library among AngularJS, React, etc. Generally, I see it as being entered by someone that doesn't know the difference (HR, a recruiter, etc.).

In my opinion, Node.js is a platform, or a runtime environment; it switches out the DOM API (JavaScript in the browser) for various other APIs, like the file system (since it runs as a server, and not in the browser).

Why is it that people think Node.js is a framework; am I wrong? Is it actually a framework?

  • 2
  • 6
    Not particularly, but I could see the confusion.
    – ndugger
    Oct 6, 2015 at 15:46
  • 1
    A long time ago, when node first came out, I posted an answer on SO that said that node wasn't a framework. That answer was extremely downvoted back then. Today, very-very few people who use node believe it's a framework. It's a framework in the same sense that Swift is a framework or Go is a framework or Rust is a framework. Modern programming languages simply have very high-level APIs that used to be implemented as frameworks. "Platform" is a good word. I'd say it's an interpreter myself (using the traditional unix meaning of that word)
    – slebetman
    Oct 6, 2015 at 21:08
  • Note that node does not switch out the DOM API and anything you can run with javascript is still available to you, with or without node.
    – Rob
    Oct 7, 2015 at 0:04
  • @slebetman What's the "other" meaning of interpreter? I didn't realize there was a debate there too! :S Oct 7, 2015 at 12:01

2 Answers 2


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:

  1. 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"
  2. Node.js, as a package, contains an interpreter and a compiler. It just steals these from V8.
  3. Node.js provides an implementation of the Node.js runtime environment which allows "Node.js JavaScript" to be executed.
  4. 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".

  • hey, remarkably balanced! so, probably have no idea: 'framework' is a word that you can understand without being a programmer, a useful feature, if spared for when it would actually make a difference.
    – n611x007
    Oct 6, 2015 at 22:21
  • "Node.js adds functionality to raw JavaScript in the way of expanding the language." Not true, it is expanding functionality and not the language, it doesn't change the way you need to write code like many frameworks require. There are other functions or objects added like an included library can add. You can call it or use it like any new function or object. The style of programming doesn't change, language basics are the same 'only' add some functionality. So it is not a framework or expanding the language, javascript with added default platform libraries and thus functionality.
    – Codebeat
    Jul 20, 2019 at 4:23
  • Sure, I can completely follow your side. I think the line here is fuzzy. Either way of thinking makes sense. As a strict point, node does expand JS by providing an FFI, which is then the core piece that lets node subsequently provide more system libraries. On the other hand, whereas “core” node is just the runtime (and this FFI), most of the time when people discuss node they actually mean “the core runtime, the FFI extensions, and basic library functionality built atop it” as this is how node is packaged. Jul 21, 2019 at 13:49

Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.


Node is a runtime or environment. It is not a framework. People (I feel) often get this wrong because frameworks like express are ubiquitous with node.

more reading on runtimes vs frameworks if you are interested.

  • inb4 "but the about page says 'As an asynchronous event driven framework'" I am aware.
    – rlemon
    Oct 6, 2015 at 15:30
  • 4
    Isn't the embedded v8 the runtime? ;-)
    – johannes
    Oct 6, 2015 at 17:30
  • @johannes I'm inclined to agree with you on this. V8 is the runtime and node simply expands the tools available to the developer (http server, util, etc) thus I think the framework label still works. Still, it is a modified v8 environment; node isn't something you just "include" in your project. It's all a matter of perspective I guess.
    – nick
    Oct 9, 2015 at 4:32
  • @rlemon, the part framework has been removed. Apr 2, 2017 at 18:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.