JavaScript: A Practical Guide

JavaScript is the language the web runs on, and the one every modern stack eventually drops you back into. React components, browser events, fetch calls, build scripts, and a great deal of AI-generated code all sit on the same runtime rules. Hide them behind a framework and they are still there, waiting patiently to explain your bug.

This page is the map of the JavaScript section. It covers what the language does, the one rule every guide below assumes, why so much older advice about it is now wrong, and where each of the thirteen guides fits. Skip to the list if you already know what you came for.

JavaScript at a Glance

The section splits into four topics. The first is the language itself; the other three are the three places it runs into trouble.

Language Basics

Covers Values, functions, objects, modules

Start here if The syntax itself is still new

Async

Covers Promises, await, fetch, timers, races

Start here if Results arrive in the wrong order

DOM

Covers Selecting, updating, events, forms, cleanup

Start here if You are wiring up a real page

Node

Covers The terminal, running files, npm, scripts

Start here if You want to run code outside a browser

What JavaScript Actually Does

JavaScript describes values and the work done on them. A value is a piece of data: a number, a string, or an object holding named fields. A function is a named piece of work you can hand values to.

An object is a bag of named values, and an array is an ordered one. Almost everything else in the language is a way of arranging those three.

The language is also loose on purpose. Nothing declared the shape of a cart item, and nothing checked it. That looseness is why you can wire up a form in ten minutes, and it is equally why a missing property, a late response, or a stale listener can reach production without anything complaining first.

Where JavaScript Came From

Early web pages were static HTML. Anything that needed to change in the page after it loaded had no language to do it with. JavaScript was added in the Netscape browser in 1995 so a page could run code on the user's machine.

The language was standardized as ECMAScript and is still that browser runtime. ES2015 added the syntax most current code uses. Node took the same language onto servers and tooling. What actually runs still depends on the engine in front of you (V8, SpiderMonkey, and JavaScriptCore).

What JavaScript Code Looks Like

const cart = [
  { name: "Notebook", price: 4.5, quantity: 2 },
  { name: "Pen", price: 1.25, quantity: 4 },
];

function cartTotal(items) {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

console.log(cartTotal(cart));

// node 24.16.0 output:
// 14

Nothing clever is happening, which is the point. An array of objects, a function that walks it, and a result printed out. The reduce call is passing a function to another function, which is the habit that runs through the whole language: work is a value you can hand around like any other.

Running the Examples

Every example on this page and in the guides below runs in one of two places, and which one you pick depends on what you are learning rather than on your level.

In a browser, right-click any page, choose Inspect, open the Console tab, and paste the code straight in. That is the right home for anything touching a page: elements, clicks, forms.

For a file you can save and re-run, install Node and run node app.js from a terminal. That is the right home for language practice and for anything with no page involved. The Node topic starts with the terminal itself if that part is the obstacle.

One Thread, Run to Completion

Here is the rule every guide in this section assumes and none of them stops to argue. Your page or script is one agent: a single thread with its own queue, where one job runs to completion before the next starts. Nothing interrupts a running function: not a click, not a timer, not a response from a server.

Work that has to wait is therefore never done by waiting. You hand the job to the host around your code, the browser or Node, and it hands you back a callback or a promise.

When the job is done that callback joins a queue, and nothing in a queue is picked up while your current job is still running.

Once it finishes, the host drains the promise callbacks that are waiting and then takes one more piece of queued work, with a browser free to paint in between. That repeating cycle is the event loop, and Node organises its own turns a little differently.

setTimeout(() => {
  console.log("the timer callback, finally");
}, 0);

const started = Date.now();
while (Date.now() - started < 2000) {
  // a busy loop standing in for slow synchronous work
}

console.log("the busy loop finished after about 2 seconds");

// node 24.16.0 output:
// the busy loop finished after about 2 seconds
// the timer callback, finally

A delay of zero, and the callback still waited two seconds, because there was one thread and the loop was holding it. In a browser that same loop freezes the page: no clicks, no typing, no scrolling, because handling those is also your thread's job.

Three consequences run through the rest of this section. Slow synchronous work blocks everything, which is why async work exists at all.

Callbacks also run later than the code around them, which is why closures matter so much in practice. And queued work has an order of its own: promise callbacks already waiting are drained at that checkpoint before the loop takes the next timer callback, which timers, ordering, and race conditions works through case by case.

Where JavaScript Fits

JavaScript is the default language of the browser, which alone makes it unavoidable for frontend work. It reads user input, responds to events, updates the page, calls APIs, holds small pieces of client state, and coordinates behaviour after the HTML has loaded.

It also runs in plenty of places with no page at all. Node powers scripts, servers, command-line tools, build tooling, and test runners, while edge runtimes use it for small request handlers close to users. The host changes and the language model stays familiar.

• Browser interactions that respond to clicks, forms, keyboard input, and page state.
• API clients that fetch data, handle failures, and update the interface afterwards.
• Small automations over files, content, data conversion, and developer workflow.
• Node scripts that glue tools together without needing a compiled binary.
• Framework code in React, Vue, Svelte, Astro, Next, and similar stacks.
• Build configuration for bundlers, test runners, linters, and code generators.

Even if you prefer TypeScript for serious application work, the JavaScript underneath is not optional. Type annotations and other type-only syntax are erased before the code runs, and a few TypeScript constructs emit real JavaScript instead. Either way closures, promises, modules, objects, this, and browser APIs behave exactly as this section describes.

Why Old JavaScript Advice Looks Wrong

JavaScript has more outdated writing about it than almost any other language, and search results do not sort themselves by age. Four things in particular will look wrong when you meet them, and knowing why saves you copying a workaround for a problem you do not have.

Answers built on var. Older code declares variables with var, which ignores block scope and behaves strangely inside loops. Most of the puzzle-shaped questions about it exist for that reason, and let and const removed the puzzle, as the values and equality guide covers.

Nested callbacks stacked into a pyramid. Before promises, every step that had to wait went inside the previous step's callback, and error handling was repeated at each level. Promises and await made that flat, and promises and async/await is where the modern shape is taught.

jQuery for things the browser now does. jQuery solved selection, page updates, and network requests back when browsers disagreed with each other, and querySelector, classList, and fetch are built in now. It is still worth learning if you maintain a codebase that uses it, but selecting elements and updating the page shows the built-in equivalents.

Module advice written before Node could detect ESM. Older answers assume any .js file without a type field is CommonJS; current Node versions can spot ESM syntax in an ambiguous file and run it. Explicit module markers and ESM's own rules still matter, and modules, imports, and exports covers the boundary as it stands.

The Problems Each Topic Solves

Code That Does Something You Did Not Write

The first problem is the language surprising you. Two values that look equal are not, an object you thought you copied changes in two places at once, or a function reads a variable that has moved on since it was written.

None of these are edge cases. They come from three design decisions you meet in the first week: comparison can convert types before comparing, an object or array value is a reference, so copying it copies the reference rather than the object, and a function keeps a live link to the variables around it rather than a snapshot.

That last one is worth stating plainly, because it is where beginners most often conclude the language is broken. A closure reads its captured variable at the moment it runs, not at the moment it was written.

So functions made in a loop share one counter when that counter is a var or lives outside the loop, while a let counter declared in the loop gets a fresh one each time round. Combine that with the event loop above and you have most of the classic confusion.

The language basics topic covers values and equality, functions and closures, objects and arrays, and modules across four guides, in that reading order.

Results That Arrive in the Wrong Order

The second problem is the one this site's readers describe most: everything works, then a request is added and the whole thing stops making sense. A variable is empty because the code that fills it has not run yet, and a search box shows the results of the query before last. A failed request gets treated as a success.

That third case deserves its own line, because it does not look like an error at all:

const response = await fetch("https://example.com/does-not-exist");

console.log(response.ok, response.status);

const data = await response.json();

// observed with node 24.16.0 against this URL:
// false 404
// SyntaxError: Unexpected token '<', "<!doctype "... is not valid JSON
// this endpoint's status, body, and parse error may change

The fetch promise fulfilled, and the response it handed back carried status 404. An HTTP error status does not reject the promise on its own, so a bad answer arrives looking like an ordinary response, and response.ok or response.status is what tells you otherwise.

The confusing failure then lands one line later, on a body that was never JSON. Checking response.ok first turns that into a message you can act on. The exact wording above is Node's; browsers phrase both errors differently.

The async topic covers promises and await, fetching data and handling requests that fail, and the timers and race conditions behind results landing out of order.

A Page That Stops Responding to People

The third problem is the browser half. A button does nothing on the second click, a form reloads the page instead of submitting quietly, or the interface slowly gets heavier the longer someone uses it.

These are ownership problems more than syntax problems. Something has to find the element, decide what changes, listen for the event, stop the browser's default behaviour, and take the listener off again when the element goes away. Miss the last step and the listeners pile up, which is the leak that survives a move to a framework.

The DOM topic covers selecting elements and updating the page, the events and forms a person actually interacts with, and the listener cleanup and loading order that keep a working feature from leaking.

A Script You Cannot Get to Run

The fourth problem is not about JavaScript at all. The code is fine and it will not run: the terminal is unfamiliar, a command is not found, a file errors on its first import, or a project's instructions assume you already know what a script entry is.

This is the wall that stops non-developers from ever using the language for their own work, and it is worth naming as a wall rather than treating it as prerequisite knowledge. Opening a terminal, checking whether Node is installed, running one file, and reading an error message are four skills, and each is smaller than it looks from the outside.

The Node topic starts with the terminal itself, then covers running a file and reading its arguments, the package.json file and npm scripts, and the file handling behind a small automation you run yourself.

Learning Path

Learn it in roughly the order that makes real code less mysterious.

1. Start with language basics: values, equality, functions, closures, objects, arrays, and modules.
2. Move to async once ordinary code is boring: promises, await, fetch, and the failures each one has.
3. Add the DOM when you want a real page to respond to a real person.
4. Pick up Node whenever you need to run something outside a browser, which is often sooner than people expect.
5. Build one small project end to end before going near a framework.
6. Add TypeScript when a project grows contracts worth writing down.

The order of the middle three is genuinely yours. Someone automating a spreadsheet should go to Node third and may never need the DOM; someone fixing a marketing site should do the reverse. Only the first step is fixed, because the other three assume it.

What JavaScript Cannot Do

It cannot type-check your work before it runs. The engine will reject broken syntax, but nothing built into JavaScript catches a misspelled property name until that line executes, which is the gap TypeScript and other static analysis tools exist to fill.

It cannot keep a secret in the browser. Anything shipped to a page can be read, so API keys, pricing rules, and permission checks belong on a server, a position application security starts from.

It cannot reach past what its host allows. A browser page cannot silently pick files off the machine, since the file APIs need the person to choose or grant them, and browser security rules limit which cross-origin responses your code may read. Node has different limits, which is exactly why the same code does not run in both places.

And one agent cannot do two things at once. Running JavaScript in parallel means a second agent, a web worker in the browser or a worker thread in Node, and those agents can share memory rather than variables.

Every Guide in This Section

Language Basics

The language itself, in the order the guides build on each other. The language basics topic holds them together.

• Values, Variables, and Equality: let and const, the primitive types, why == converts before comparing, and what counts as falsy.
• Functions, Callbacks, and Closures: declarations against expressions, arrow functions and this, callbacks, and the live variables a closure keeps hold of.
• Objects, Arrays, and Destructuring: property access, map and filter and reduce, spread and rest, and the difference between copying and sharing.
• Modules, Imports, and Exports: named and default exports, import paths, the ESM and CommonJS boundary, and script loading order.

Async

Everything that finishes later than the line that started it. All three sit under the async topic.

• Promises and async/await: the three states a promise can be in, chaining, await, waiting on overlapping work, and where errors actually surface.
• Fetch, JSON, and the Network: reading a response, response.ok, sending a POST, telling a bad answer from no usable answer, and cancelling with AbortController.
• Timers, Ordering, and Race Conditions: setTimeout and setInterval, what actually runs first, the stale-response bug, and debouncing typed input.

The DOM

The browser half: finding things on a page, changing them, and listening to a person. The DOM topic covers how the three connect.

• Selecting Elements and Updating the Page: querySelector, textContent against innerHTML, classes, data attributes, and building nodes.
• Events, Forms, and User Input: addEventListener, the event object, preventDefault, delegation, and submitting a form with FormData.
• Listener Cleanup and Page Lifecycle: removing listeners, AbortController on events, when a script is allowed to run, and why leaks outlive a rewrite.

Node

JavaScript with no page in sight, starting from the terminal. The Node topic is the entry point.

• Running JavaScript with Node: installing and checking versions, running a file, arguments, printed output, and exit codes.
• package.json, npm, and Scripts: the fields that matter, dependencies against devDependencies, npm scripts, and what a lockfile is for.
• Files, Environment Variables, and Small Automations: reading and writing files, paths, environment variables, and one bulk-edit script worth stealing.

Related Languages

• TypeScript: the same runtime with a type checker in front of it, for code that has outgrown being held in your head.
• JavaScript vs TypeScript: the decision itself, if you are weighing whether that step is worth taking yet.
• HTML: the document structure the DOM guides spend their time changing.
• CSS: styling, layout, and states, which is often the better tool for behaviour you were about to script.
• Python: the stronger choice when data work and scripting matter more than running in a browser.
• Programming: the wider language index, including the data and database guides.

Frequently Asked Questions

Which topic should you start with?

Language basics, unless you already write JavaScript comfortably. Async is the topic most people are actually stuck in, but promises are hard to reason about before closures make sense. The DOM and Node topics are chosen by where your code runs rather than by order.

What is the difference between JavaScript and Java?

They are unrelated languages that share part of a name for historical marketing reasons. Java is a statically typed language that usually runs on the JVM; JavaScript is dynamically typed and runs in browsers and in runtimes such as Node.

What is the difference between JavaScript and ECMAScript?

ECMAScript is the standard that defines JavaScript, and engines such as V8, SpiderMonkey, and JavaScriptCore implement it. Names such as ES2015 refer to editions of that standard, while whether a feature actually works still depends on the browser or runtime version in front of you.

Do you need a framework to learn JavaScript?

No, and starting with one usually slows you down. The DOM, events, and asynchronous behaviour are the foundation every framework sits on. Learn those first, then a framework makes sense because you can see what it is doing for you.

Do you need Node to learn JavaScript?

Not for browser work, where the console in your developer tools runs code immediately. Reach for Node once you want to run a file on your own machine, script outside a page, or use the tooling most projects are built with. Deno and Bun run JavaScript files too; this section teaches Node.

Is JavaScript single threaded?

One agent, meaning one page or one script, runs its jobs on a single thread and finishes each one before starting the next. Workers are separate agents with their own threads, and agents can share memory, so JavaScript as a whole is not limited to one thread.

Should you learn TypeScript as well?

Eventually, once JavaScript itself is not the thing confusing you. TypeScript checks the shapes your code expects, and its type-only syntax is erased before execution while a few constructs emit JavaScript. Either way, every runtime rule on this page still applies underneath it.

Should you learn JavaScript or Python first?

Pick by what you want to build. JavaScript is the only language that runs natively in a browser, so it wins for anything on the web, while Python is stronger for data, scripting, and automation. Both are reasonable first languages.

What to Build First

Build one small feature with real inputs and real failure paths. A newsletter form is enough if you treat it seriously: validate the field, call an API, handle a failed request, disable the button while it is in flight, show a result, and take the listeners off again if the form can disappear.

That one exercise touches values, closures, events, a promise, a fetch that can fail, and cleanup, which is most of what this section teaches. Walk through language basics if any of the syntax is still doing the confusing, then async, and read the DOM guides alongside the build rather than before it.

When that feels ordinary, a framework is the next step, and it will be a smaller one than it looks. The organisation changes; the runtime rules on this page stay exactly where they are, still explaining your bugs.