JavaScript tools: your real working environment

Learn how to build a solid technical setup with VS Code and DevTools so you can run, inspect and debug JavaScript from the very beginning of the course.

How much do you know about JavaScript?

📘 Theory

A simple environment architecture for learning well

Three pieces, three responsibilities: editor, runtime and diagnosis.

To progress in JavaScript, you need to separate where you write code, where it runs and where you inspect the result. Mixing those roles creates confusion very quickly.

Once those layers are clear, debugging becomes a method instead of a guessing game. That is one of the highest-value habits you can build at beginner and intermediate level.

Editor

VS Code for writing, navigating and organizing files quickly.

Execution

The browser for frontend scripts and Node.js for local scripts.

Diagnosis

Console, breakpoints and structured messages to locate failures.

Iteration

Small changes, fast checks, observation and continuous adjustment.

VS Code: the minimum setup that actually helps

Start simple and avoid early overconfiguration.

A clean VS Code setup reduces cognitive noise: a readable theme, a clear folder structure and just a couple of tools that improve code quality.

You do not need twenty extensions. For this course, the priority is readability, intentional saving and useful feedback while you type.

Create one folder per project instead of scattering files across the desktop.
Use save as a mental checkpoint while you work.
Install ESLint and Prettier and understand what each one corrects.
Name files predictably, for example `app.js`, `main.js` or `utils.js`.

DevTools: use the console with intention

It is not just a panel for random logs. It is an investigation tool.

Open DevTools with F12 and get used to reading complete errors: type, message, file and line. That is the shortest path to the real cause.

Beyond `console.log`, use `console.warn` and `console.error` to classify signals so important information does not disappear once projects grow.

`console.log` for normal state and intermediate values.
`console.warn` for suspicious but recoverable situations.
`console.error` for failures that break the expected flow.
Breakpoints for validating one hypothesis at a time.

Browser runtime vs Node.js runtime

Same language, different APIs depending on where the code executes.

JavaScript is the language, but the runtime decides which globals and APIs are available. In the browser you get `window` and `document`; in Node you get `process` and filesystem-related modules.

Understanding that boundary avoids classic mistakes such as trying to use `document` in a Node script or assuming Node APIs exist inside the browser.