Module 41: Node.js Fundamentals

Why each option is right or wrong

• “Yes, Node.js includes every browser feature” (Incorrect): Node leaves out page features like document and window.
• “Yes, but only after installing the latest version of Node” (Incorrect): No Node version adds a real page to run on.
• “Only if the code is saved with an .html extension” (Incorrect): File names don't change what Node provides.
• “No, there's no web page or DOM in Node.js” is correct.

  document is provided by the browser to represent the page it's showing. Node.js runs JavaScript on a server or your computer, with no page to show, so document doesn't exist there and the code throws a ReferenceError.

  • Same language, different tools: browsers give you the page; Node gives you files, network and processes.
  • Testing UI in Node: tools like jsdom imitate a page for tests.

📖 Revise: Lesson 1: The Node.js runtime

Why each option is right or wrong

• “Show pop-up alerts to the person using it” (Incorrect): That's alert, a browser feature that Node doesn't have.
• “Respond to mouse clicks on the page” (Incorrect): Clicks happen in the browser; Node has no page.
• “Change the colour of elements on the page” (Incorrect): Styling the page is the browser's job.
• “Read and write files on the computer” is correct.

  Browsers keep web pages away from your files for safety. Node.js runs with your own permissions, so its fs module can read and write files, which is how servers save data, logs and uploads.

  • With power comes care: Node code can delete files too.
  • Browsers: only access files a person picks in a file dialog.

📖 Revise: Lesson 1: The Node.js runtime

Why each option is right or wrong

• “No, it's created automatically, so it can be left out of Git” (Incorrect): Being generated doesn't make it disposable; it records the exact versions everyone should get.
• “No, npm recreates it the same way every time” (Incorrect): Without it, npm may pick newer versions within the allowed ranges.
• “Only if the project has more than ten packages” (Incorrect): Even small projects benefit from repeatable installs.
• “Yes, so everyone installs exactly the same versions” is correct.

  package.json often allows a range of versions, like ^4.18.0. The lock file records exactly which versions were installed, so teammates and the server get the same ones, avoiding "works on my machine" problems.

  • Install from it: npm ci uses the lock file exactly.
  • Ignore: node_modules, not the lock file.

📖 Revise: Lesson 2: npm and package.json in depth

Why each option is right or wrong

• “Nothing; npm checks every package for safety” (Incorrect): npm scans for some known problems but can't vouch for every package.
• “Only its download size, so the app doesn't get slower to install” (Incorrect): Size matters less than whether it's safe, maintained and actually needed.
• “Whether its name sounds professional” (Incorrect): A convincing name is exactly what look-alike packages use.
• “Whether it's needed, maintained, trusted and not a look-alike name” is correct.

  Attackers publish packages with names close to popular ones, hoping someone installs them by mistake, and AI tools sometimes suggest packages that don't exist or aren't what they seem. Check whether you need it at all, who publishes it, when it was last updated and whether the name is exactly right.

  • Look at: the npm page, the repository, recent releases and open issues.
  • Often better: a few lines of your own code or a well-known package.

📖 Revise: Lesson 2: npm and package.json in depth

Why each option is right or wrong

• “tsc makes the code run faster” (Incorrect): tsc --noEmit only checks; it doesn't change how the code runs.
• “Node can't run TypeScript without first compiling it with tsc” (Incorrect): Recent Node versions can run it directly; they just don't check it.
• “tsc uploads the code to the server” (Incorrect): tsc checks types; it doesn't deploy anything.
• “Node removes types without checking them; tsc checks” is correct.

  Node's built-in TypeScript support simply strips the types and runs the JavaScript left over. Type errors go unreported. tsc --noEmit runs the full checker without writing any files.

  • Routine: run it before each commit or in CI.
  • Errors it catches: wrong types, missing properties, typos in names.

📖 Revise: Lesson 3: Modules in a backend project

Why each option is right or wrong

• “It can only read text files, not JSON” (Incorrect): It can read any file; the problem is blocking.
• “It loads the whole file into memory, which can crash the server” (Incorrect): Memory can matter for huge files, but the main problem is that it blocks every request.
• “It deletes the file after reading it” (Incorrect): Reading doesn't delete anything.
• “It blocks the single thread, so every other request waits” is correct.

  Node handles all requests on one main thread. readFileSync stops that thread until the file is read, so other visitors wait too. The async version, await readFile(...), lets Node serve others in the meantime.

  • Fine at start-up: reading config once before the server starts.
  • In handlers: use fs/promises.

📖 Revise: Lesson 4: Asynchronous I/O

Why each option is right or wrong

• “It starts a new copy of itself for each visitor” (Incorrect): One process serves many visitors; it doesn't copy itself.
• “It handles one person at a time very quickly” (Incorrect): It interleaves many requests rather than handling them one by one.
• “Each request runs on its own processor core” (Incorrect): Your JavaScript runs on one main thread, not one core per request.
• “It doesn't wait during I/O; it handles other requests until results are ready” is correct.

  Most of a server's time is spent waiting for files, databases and networks. Node starts these operations, moves on to other requests, and picks up each result when it's ready, through the event loop.

  • Good at: many requests that mostly wait on I/O.
  • Weak at: heavy calculations, which block the thread.

📖 Revise: Lesson 4: Asynchronous I/O

Why each option is right or wrong

• “Git refuses to commit files whose names start with a dot” (Incorrect): Git commits dot-files, like .gitignore; .env is left out on purpose to protect secrets.
• “Node can only read files called .env.example” (Incorrect): Node (or a loader) reads .env; the example is documentation.
• “The example is the one the live server uses” (Incorrect): The live server uses its own real settings, not the example.
• “The example shows needed settings without exposing real secrets” is correct.

  .env holds real passwords and keys, which shouldn't be in Git history. .env.example lists the same setting names with placeholder values, so a new developer knows exactly what to set up.

  • Example line: DATABASE_URL=postgres://user:password@localhost/db.
  • Keep it updated: add new settings to the example as you add them.

📖 Revise: Lesson 5: Environment configuration

Why each option is right or wrong

• “Restarts the server automatically whenever it crashes in production” (Incorrect): That's a process manager's job. --watch restarts on file changes during development.
• “Prints a live log of every request the server receives” (Incorrect): It doesn't log requests; it reruns the program when files change.
• “Runs the tests every hour” (Incorrect): It restarts the program on file changes; it doesn't schedule tests.
• “Restarts the program automatically when you save a file” is correct.

  During development, --watch keeps an eye on your files. When you save a change, it restarts the program, so you see the result without stopping and starting it by hand.

  • For development only: production servers run without it.
  • Older projects: used a tool called nodemon for the same job.

📖 Revise: Lesson 1: The Node.js runtime

Why each option is right or wrong

• “It makes the server start faster by loading settings ahead of time” (Incorrect): It adds a tiny check; the benefit is a clear error straight away.
• “Environment settings can't be read once the server has started” (Incorrect): They can, but finding a missing one late is confusing.
• “It hides the settings from the logs” (Incorrect): It checks they exist; hiding secrets is a separate concern.
• “A missing setting fails immediately with a clear message” is correct.

  If DATABASE_URL is missing and nothing checks, the server starts, then fails confusingly on the first request that needs it. Checking at start-up stops with "DATABASE_URL is not set", right when the mistake is easiest to fix.

  • Fail fast: problems show up at deploy time, not in front of users.
  • Tools: a small config module, or a schema with Zod.

📖 Revise: Lesson 5: Environment configuration