Code review Monday morning. A junior dev shows me his React component. Clean, hooks properly separated, state management looks fine. I ask him to explain why his useEffect
has an empty dependency array. He hesitates. "So it runs only once." Alright, but why? What happens if you add a dependency? Silence. He didn't know. Claude wrote the hook, he copied it, it worked. Six months of React and he'd never written a raw addEventListener
.
JavaScript is the most copy-pasted language on the planet. It was true with Stack Overflow, it's worse with AI. The language is everywhere — front-end, back-end, mobile, serverless, build scripts — and that ubiquity creates an illusion: you think you know JS because you run JS code. But if you don't understand the event loop, closures, the behavior of this
, or the difference between ==
and ===
, you're building on sand. This article explains how to use Claude to actually learn JavaScript — the language, not whatever framework is trending this month.
"AI writes JS better than me, why bother?" Three pragmatic reasons.
1. JavaScript has more traps than any other mainstream language. Type coercion, this
changing based on call context, hoisting, temporal dead zone, prototypes vs classes. AI generates code that avoids these traps — but the day you need to debug legacy code full of var
declarations and 6-level nested callbacks, you're the one reading the code, not Claude.
2. The ecosystem moves faster than AI updates. New browser API, new runtime (Bun, Deno), new React pattern — Claude knows the version from a few months ago. If you understand the fundamentals, you adapt. If you only understand Claude's answers, you're stuck the moment the context changes.
3. Front-end is visible. Your Python bug crashes silently on a server. Your JavaScript bug breaks the interface in front of the user, in production, in real time. The cost of a TypeError: Cannot read properties of undefined
in production is immediate and visible. Understanding JS deeply isn't a luxury — it's risk management.
The generic anti-patterns of AI-assisted learning (blind copy-paste, never writing first, skipping debugging) all apply. But JavaScript has its own special traps.
AI always uses ===
. Good. But if you don't know why, you don't understand type coercion — and you can't read legacy code that uses ==
everywhere.
// Looks innocent...
console.log(0 == ''); // true
console.log(0 == '0'); // true
console.log('' == '0'); // false — wait, what?
console.log(null == undefined); // true
console.log(null === undefined); // false
// The rule: use === everywhere. But understand WHY.
// == does type coercion before comparison.
// === compares value AND type, no conversion.
this
this
in JavaScript doesn't work like in other languages. Its value depends on how the function is called, not where it's defined. AI writes arrow functions everywhere to avoid the problem. The day you encounter code with bind
, call
, or apply
, you're lost.
const user = {
name: 'Alice',
greet() {
console.log(`Hello, ${this.name}`);
}
};
user.greet(); // "Hello, Alice" — ok
const greetFn = user.greet;
greetFn(); // "Hello, undefined" — this is lost
// Arrow function = lexical this (inherits from parent scope)
// Regular method = this depends on the call site
// Two different rules. You need to know both.
async/await
is syntactic sugar over Promises. If you've never written a Promise
by hand, you don't know what happens when your await
fails, when you forget the try/catch
, or why your "asynchronous" code sometimes blocks.
// What AI writes:
const data = await fetch('/api/users').then(r => r.json());
// What you should understand first:
const promise = fetch('/api/users'); // returns a Promise, not the data
promise.then(response => { // .then() is called when the response arrives
return response.json(); // .json() ALSO returns a Promise
}).then(data => {
console.log(data); // the actual data
}).catch(error => {
console.error('Network error:', error);
});
// async/await is more readable, but it's the same mechanics underneath.
// If you don't understand Promises, you can't debug async/await.
React, Vue, Angular — everyone wants to start there. It's the worst learning decision you can make. Frameworks hide JavaScript. useState
hides state management. JSX hides DOM manipulation. The bundler hides modules. You learn the framework, not the language. And when the framework changes (which happens every 2 years), you start over.
JavaScript is single-threaded with an event loop. If you don't understand this, you don't understand why setTimeout(fn, 0)
doesn't execute fn
immediately, why a heavy for
loop blocks the UI, or how Node.js handles thousands of concurrent requests with a single thread.
console.log('1');
setTimeout(() => {
console.log('2');
}, 0);
Promise.resolve().then(() => {
console.log('3');
});
console.log('4');
// Output: 1, 4, 3, 2
// Not 1, 2, 3, 4. Not 1, 4, 2, 3.
// Why? Microtasks (Promises) run BEFORE macrotasks (setTimeout).
// If you don't know this, you can't reason about async code.
Same discipline as for any language (I also cover this in the Python guide): write first, ask for review after, rewrite yourself. But adapted to JS specifics.
Problem: filter an array of objects and transform the result. Write your solution, even if it's 20 lines with for
loops.
// My version — find active users and extract their names
function getActiveUserNames(users) {
const result = [];
for (let i = 0; i < users.length; i++) {
if (users[i].active === true) {
result.push(users[i].name.toUpperCase());
}
}
return result;
}
Here's my JavaScript code to filter active users and extract their names. Don't give me a corrected version. Tell me what could be improved and why, and let me rewrite it myself.
Claude will point out: the === true
comparison is redundant if active
is already a boolean. The classic for
loop can be replaced with filter
map
to express intent more clearly. But it lets you rewrite.
// My improved version after review
function getActiveUserNames(users) {
return users
.filter(user => user.active)
.map(user => user.name.toUpperCase());
}
You wrote both versions. You understand the difference between an imperative loop and a functional chain. You know that filter
returns a new array (no mutation), that map
transforms each element. It's in your head.
Here's my improved version. What am I not seeing? Is there a case where this approach breaks?
Claude will mention: filter
map
iterates the array twice. For thousands of elements, reduce
does both in a single pass. And if user.name
can be null
, it blows up without optional chaining.
// Defensive version with reduce
function getActiveUserNames(users) {
return users.reduce((names, user) => {
if (user.active) {
names.push(user.name?.toUpperCase() ?? 'UNKNOWN');
}
return names;
}, []);
}
Three approaches, three levels of understanding. You wrote the first two. The third, you understand because you walked the path — reduce
isn't magic anymore, it's a disguised for
loop with an accumulator.
The difference between learning and delegating often comes down to how you phrase the prompt. Here are patterns adapted to JavaScript.
❌ Passive prompt
✅ Pedagogical prompt
"Write a debounce function for an input"
"I tried writing a debounce with setTimeout
. My timer doesn't reset when I type again. What am I missing?"
"Fix this async code"
"This fetch
returns undefined
instead of data. I added await
but nothing changed. Explain what's happening without giving me the fix."
"Write an event listener for a form"
"I wrote form.addEventListener('submit', handleSubmit)
but the page reloads. Why and how do I prevent it?"
"Make me a fetch API call"
"I wrote this fetch
POST. Why do I have to call .json()
separately? And what happens if the server returns a 404 — does the catch
fire?"
"What are closures?"
"I understand a closure captures variables from the parent scope. But in this for
loop with var
, every callback logs the same number. Why?"
The common pattern: show what you did or understood, then ask a specific question. Not "explain Promises" but "I understand .then()
but I can't see why my .catch()
doesn't catch the error from the second .then()
." Claude adapts its response to your actual level.
A path that worked for people I've mentored. The golden rule: no framework before week 7. Yes, it's tempting. No, it's not negotiable.
Variables (const
by default, let
when you need reassignment, never var
), primitive types, conditions, loops, functions, arrow functions. Without Claude. Use MDN Web Docs — it's the best JS reference out there, and it's free.
Exercise: write a Node.js script (no browser) that reads a JSON file, filters data based on a criterion, and writes the result to a new file. Just fs.readFileSync
, JSON.parse
, filter
, JSON.stringify
, fs.writeFileSync
. When done, ask Claude for a review.
document.querySelector
, addEventListener
, createElement
, classList
, fetch
. You build interactive pages without any framework. Here you start using Claude in review mode.
Exercise: a todo list in vanilla JS. An input, a button, a list. Add, delete, toggle complete. Persist in localStorage
. Zero dependencies. If you need jQuery for this, you don't know the DOM yet — and that's exactly the point of the exercise.
import
/export
(ES modules), package.json
, npm, node:fs/promises
, node:path
, basic HTTP server. Claude becomes a patterns teacher: "why ES modules instead of CommonJS?", "when to use require
vs import
?", "why node:fs/promises
and not fs
with callbacks?".
Exercise: a small REST API with Node's native http
module. Not Express, not Fastify — just http.createServer
. Manual routes, body parsing, JSON responses. You'll understand exactly what Express does for you (and it'll make Express 10x clearer when you eventually use it).
Now you can touch a framework — but you know what's happening underneath. Some calibrated ideas:
popstate
), HTML templates, fetch against a public APIprocess.argv
, terminal colors, error handlingClaude switches to pair programming mode: you write a feature, you discuss architecture with it, it challenges your choices. "Why are you storing state in a global variable instead of an object?" — if you can't answer, you haven't consciously decided yet.
Two tools, two very different execution contexts for JavaScript.
Web interface, conversation. The right tool for:
Advantage: accessible, no terminal needed, ideal for weeks 1-4 when you're working in the browser console. Limitation: it can't see your project, you copy-paste.
In the terminal, directly in your project. The right tool for:
package.json
, your testsAdvantage: full project context, real execution, file management. Limitation: more technical to set up, requires a terminal.
Weeks 1-4: Claude Pro + the browser console. Open DevTools (F12), test snippets, ask Claude questions about what you observe. No need for Node or a terminal at this stage. Weeks 5-8: Claude Code in your Node.js project. You need file context, modules, tests, live debugging. Claude Pro remains useful for conceptual questions in parallel.
Claude writes correct JavaScript. But correct code and professional code are two different things. These conventions are learned by reading good code and getting corrected — not by asking "write me a script."
const
by defaultlet
only when you need reassignment. var
.var
is problematic (hoisting, function scope instead of block scope) unless you ask.import/export
is the standard. require()
is legacy. AI often mixes both in the same project.camelCase
for variables and functions, PascalCase
for classes and componentsget_user_name
to getUserName
unless you flag it.button.addEventListener('click', handleClick)
is more readable and debuggable than button.addEventListener('click', () => { ... })
. Your stack traces will thank you.fetch
gets its try/catch
, every Promise gets its .catch()
. AI regularly forgets the catch
on non-awaited Promises — and you're the one who'll get UnhandledPromiseRejection
in prod.How do you know if you're actually learning JavaScript or just becoming a prompt operator with a console open? Three concrete tests.
Test 1 — The whiteboard. Take a problem you solved with Claude last week. Rewrite it from memory in an empty file, no AI, no MDN. If you're stuck on reduce
syntax or how to attach an event listener, you didn't learn — you delegated.
Test 2 — The explanation. Open the DevTools console. Write a piece of code you used this week. Explain every line out loud. If you say "this part I'm not sure what it does" in front of a .bind(this)
or a ?.
, that's a gap in your understanding.
Test 3 — Debugging without a net. Open a project you built with Claude. Introduce a bug: change a ===
to ==
, forget an await
, use var
instead of let
in a loop. Close Claude. Find the bug with DevTools, console.log
, and the debugger. The time it takes measures your real autonomy.
JavaScript is the language where copy-paste causes the most damage. Because it's everywhere, because it has more implicit traps than any other mainstream language, and because the framework ecosystem encourages building without understanding the foundations. AI amplifies this problem — or solves it, depending on how you use it.
The discipline is the same: write first, ask second, rewrite yourself. But in JavaScript, there's an extra rule: learn the language before the framework. Two months of vanilla JS make React, Vue, or Angular transparent. Two months of React without vanilla JS make everything opaque.
The same workflow applies to any language. I've written equivalent guides for Go and Python. The PHP guide is coming soon.