Running JavaScript

Running code is how you turn syntax into feedback. Every senior engineer still uses the same basic loop daily: change source, execute, read errors or output, repeat. This lesson maps the environments you will actually use — browser console, Node REPL, script files — and explains what the engine does before your first line prints anything.

Four practical ways to run JavaScript

Before frameworks, bundlers, or tests — you need one reliable loop: write code → run code → read output. Frameworks hide this loop behind dev servers, but when something breaks at 2 AM you fall back to console.log and stack traces. These four entry points cover almost all learning, debugging, and interview workflows. Master them once; every future tool builds on top.

Browser console: instant feedback

Open DevTools on any page and type expressions. The console evaluates each line in the context of the current page — same global object, same cookies, same DOM. Expressions (like 2 + 2) print their return value automatically. Statements (like const x = 1) do not print unless you wrap them in console.log. That distinction matters when you wonder why your REPL "shows nothing" after declaring a variable.

In the browser, the console is also where you inspect network failures, test fetch calls, and probe objects as expandable trees. console.table is underrated for arrays of rows (API results, user lists). None of this replaces a debugger, but it is the fastest way to answer "what is in this variable right now?"

Node.js REPL and script files

From disk to output, the engine pipeline is predictable. First it reads bytes and parses them into an Abstract Syntax Tree (AST). If grammar is invalid, you get SyntaxError and nothing executes — not even lines above the typo if the parser cannot recover. If parsing succeeds, the engine compiles and runs code. ReferenceError and TypeError happen during execution when a name or operation is invalid at runtime. Reading the line number in the stack trace tells you which phase failed.

Node.js embeds the V8 engine without a browser chrome. The REPL (Read-Eval-Print Loop) reads each line you type, evaluates it in Node's global context, prints the result, and waits for the next line. You get process, Buffer, and module loading — but no window or document. Script files (.js) are how real tools run: importers, seed scripts, CI jobs, and API servers all start as node path/to/file.js.

$ node hello.js AceDevHub
Hello, AceDevHub!
Node version: v22.x.x

What the engine does with your file

1. 1Read source text from disk or network
2. 2Parse into an Abstract Syntax Tree (AST) — catch SyntaxErrors here
3. 3Compile hot paths to optimized machine code (JIT)
4. 4Execute top-to-bottom, calling functions as needed
5. 5Print to stdout/stderr or return values to the REPL

Strict mode and sloppy mode

Early JavaScript allowed footguns: assigning to undeclared variables created globals; deleting built-ins was possible in sloppy mode. Adding "use strict" at the top of a file or function opts into strict mode — the engine throws instead of guessing. Modern ES modules and class bodies are strict by default, which is why new code rarely needs the string literal. Strict mode is one reason let/const errors are safer than var: combined with block scope, you get failures at the line of the mistake instead of silent corruption elsewhere.

1

1. 1Use browser console for quick DOM and API experiments
2. 2Use node file.js for repeatable scripts and backend logic
3. 3Read error types: SyntaxError (parse) vs ReferenceError (runtime)
4. 4Prefer strict mode — it surfaces bugs early
5. 5Next lesson: declare variables with let, const, and var