Node.js
What your quote means when it says the backend runs on Node
The short answer
Node.js is JavaScript running on a server instead of in a browser. It's a runtime, not a framework, so the thing your proposal actually describes is usually Express or NestJS built on top of it. It handles a lot of waiting at once very well, and heavy computation badly.
Somebody quoted you a backend and the word in it is Node. Nothing in that sentence tells you whether it's a language, a product, or a decision that costs you money in year two. It's none of those exactly, and the difference is worth five minutes.
It's a runtime, and the framework on top is what the quote means
The confusion is a category error. JavaScript is the language, built for the browser, and for years that was all it ran in. Node lets it run on a server too.
A runtime is the program that reads your code and runs it, plus the abilities it hands that code: reading a file, opening a network connection. A browser withholds both.
It's free and open source, looked after by a foundation rather than one company, and it runs on V8, the engine Google wrote for Chrome. Nobody licences it. The bill is the machine.
It doesn't give you an application, though. A framework sits in between, and which one tells you more than the word Node does. Express is small, old, and decides almost nothing for you. NestJS is the opposite bet: more structure to learn, a shape another firm recognises.
Your application code
What you pay for
The rules of your business, in JavaScript or TypeScript.
Framework and packages
Chosen at the start
Express or NestJS handling routes and requests, plus whatever else came from npm.
Node itself
The runtime
The engine, the event loop, access to files and networking. No vendor.
A server you rent
Your bill
Node is a process on a machine. Any host that runs Node will do.
What it was built to solve, which explains the rest
Picture a server holding connections that are mostly doing nothing. A request comes in, the server asks the database for something, then waits, milliseconds at a time but constantly.
The older answer gave each request its own thread and let it sit blocked. Threads cost memory, so you pay for connections that are idle.
Node made waiting the default. One thread runs your JavaScript. Anything that waits, a database query, somebody else's API, a file being read, gets handed off and that thread picks up the next request. When the result arrives, the paused work resumes.
01
Request arrives
Someone loads a page, or another system calls your API.
02
Waiting is handed off
A database query or a call to another service goes out. Node doesn't watch it.
03
Next request starts
The same thread begins the next one while the first waits.
04
Each answer returns
Results come back, paused work resumes, and a slow query hasn't held the queue.
What it's genuinely good at
Anything that spends most of its time waiting on something else. An API stitching together three others. A service holding thousands of connections open so a screen updates without a refresh. Node does a lot of that at once on unremarkable hardware.
The second advantage isn't technical, and for a smaller company it's the bigger one. One language across both halves means one hiring pool, and a developer who finds a bug on the front end can follow it into the back.
Node is probably on the project anyway, running the build tooling for the browser side. And Next.js, if the proposal names it, is built on Node rather than an alternative.
Where it stops, and it's computation rather than traffic
One thread runs your JavaScript. That's fine while it's mostly handing off things that wait. Give it work that actually computes and everything else stops.
Resizing a large batch of images, generating a long PDF, running a model in the same process. While that runs, every other request queues behind it. Nothing crashes. The site goes quiet, which is harder to spot.
That's a constraint, not a slur. The answer is to keep such work off the request path: a queue and a separate worker, or the extra threads Node provides. Neither happens by accident.
One boundary deserves naming. If the hard part of what you're building is numerical or machine learning work, the mature libraries live in Python, and Node means calling out to Python anyway.
npm is the best and the worst of it
Node ships with a package manager called npm, and behind it a registry of ready-made packages larger than any other ecosystem's. Whatever the odd requirement, somebody has published something for it. That's a real reason projects move quickly here.
The cost arrives quietly. A package you chose pulls in packages you didn't, and a modest application ends up carrying far more code than anybody picked. Most of it is fine. Some gets abandoned. Occasionally one changes hands and the new owner has bad intentions.
The habits that contain it are dull. A lockfile committed so the same versions install every time. A scheduled look at what's out of date. A preference for writing twenty lines over adding a dependency.
So the sprawl reputation is earned. It's a discipline problem rather than a property of the runtime, which makes it somebody's job.
Who has to be around after launch
The runtime moves underneath you. Major versions arrive on a published schedule: the even-numbered ones become the long-term support line and are maintained for years, the odd-numbered ones aren't. A server that drops off a supported line stops getting security fixes, and nothing announces it.
So somebody owns three recurring jobs: keeping the Node version on a supported line, keeping dependencies moving, and being reachable the morning an update breaks something. All three happen only when a name is written next to them.
The hiring picture is good, with one caveat. Plenty of people know JavaScript. Fewer have run a server in production. Someone excellent in a browser can be new to logging, memory and three in the morning.
Settle who that person is before anyone argues about the platform. It changes the answer more than the platform does.
Worth knowing before you start
Ask which framework, not just which runtime. Node means Express, NestJS or Fastify underneath, and that choice decides how readable the code is to the next firm.
Ask which Node version it will run on and whether that line is still supported. Even-numbered versions get years of maintenance. Odd-numbered ones don't.
Ask where the slowest job runs, whether that's the monthly export, the PDF or the image processing. If it runs inside the web request, everything else waits behind it.
If you're inheriting a Node project, check that a lockfile is committed and when it last changed. One that hasn't moved since launch means nobody has touched the dependencies, which is a bill nobody has paid.
Common questions
Node runs the code. Express is a small framework on top that handles the routine parts of a request: routes, incoming data, responses. Almost nothing is built against Node alone, so the framework name says more than the runtime name.
For work that mostly waits, yes, and it holds a lot of it at once on modest hardware. For work that computes, it's the wrong question: one thread runs your JavaScript, so a heavy calculation makes everything else wait.
For anything sizeable, yes. TypeScript is JavaScript with types: you state what kind of thing a value holds, and a checker flags the mismatches before the code runs. It costs some setup and catches mistakes that otherwise surface in production.
It does. Two ecosystems means two sets of hosting, dependency and hiring conventions, which is real overhead for a small team. Node earns that when the front end is already JavaScript and the server mostly waits on other systems. Otherwise Python is the cheaper answer.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.