What is JavaScript?

Think of a web page as a body. HTML is the skeleton — the structure, the bones that give it shape (headings, paragraphs, buttons). CSS is the appearance — skin, clothes, styling. JavaScript is the nervous system: it's what senses something happening (a click, a keystroke, a timer, a server response) and makes the page actually react to it. Without JavaScript, a web page is a static document — it can look good, but it can't do anything. A button that doesn't run JavaScript when clicked is just a styled rectangle.

Technically: JavaScript is the only programming language that every major browser executes natively, with no plugin and no compilation step required — you write it, the browser runs it. It is single-threaded: only one piece of JavaScript code runs at any given instant, on what's called the call stack. But browsers still manage to handle timers, network requests, and user clicks without freezing the page, because of a mechanism called the event loop — JavaScript hands off slow work (a fetch call, a setTimeout) to the browser's own Web APIs, and only picks the result back up on the call stack once it's ready and the stack is clear.

Why JavaScript?

Before JavaScript, the web was read-only documents — you clicked a link, the server sent back a whole new page, and that was the entire interaction model. JavaScript solved that: it lets a page respond immediately, in the browser, without a round trip to the server for every single action — validating a form as you type, showing a dropdown, updating part of a page after a button click. That's the "interactivity" problem, and it's still the core reason JavaScript exists on every page you use.

The second reason it still matters, arguably more now than ever: JavaScript is no longer just a browser language. Node.js lets the same language run on a server, meaning a team can write both the frontend and the backend of an application in JavaScript — one language, two environments. Combined with npm (the largest software package registry that exists), that's why JavaScript sits at or near the top of nearly every "most used programming language" survey, year after year.

Learning Modules

Module 01 — Core Syntax & the DOM

Variables, functions, and making a page react to real user actions

Topics covered:

Module 02 — Asynchronous JavaScript

Why JavaScript doesn't freeze while waiting on slow things, and how to write code that waits correctly

The event loop is the single most-asked-about JavaScript interview topic for a reason: it's the mechanism behind almost every real async bug (a page that "flashes" old data before new data arrives, a console.log that fires in the wrong order). Understanding it is not optional if you plan to write real JavaScript.

Topics covered:

Module 03 — Modern ES6+ & Modules

The syntax that's been standard, stable, and expected in any real JavaScript codebase for years

Topics covered:

Production Example

// Production Runbook — "the cart total sometimes shows the PREVIOUS item's price"

// Symptom: user clicks "Add to Cart" fast, and the total displayed
// occasionally reflects the item clicked before the most recent one.

// Step 1: Reproduce -- this smells like a race condition between two
// in-flight fetch() calls, not a math bug. Confirm by logging arrival order.
async function addToCart(itemId) {
  console.log("fetch started for", itemId);
  const res = await fetch(`/api/price/${itemId}`);
  const data = await res.json();
  console.log("fetch finished for", itemId);   // <- these two logs interleave
  updateCartTotal(data.price);                  // out of order under fast clicks
}

// Step 2: Confirm the diagnosis -- two fetches started close together can
// resolve in EITHER order, because network timing is not guaranteed to
// match request order. The second click's fetch can finish before the
// first click's fetch, and then the first click's slower response arrives
// LAST and overwrites the correct total with stale data.

// Step 3: Fix -- track only the latest request, ignore stale responses
let latestRequestId = 0;

async function addToCartFixed(itemId) {
  const requestId = ++latestRequestId;
  const res = await fetch(`/api/price/${itemId}`);
  const data = await res.json();

  if (requestId !== latestRequestId) {
    console.log("ignoring stale response for", itemId);
    return; // a newer click has already started a request; this one is stale
  }
  updateCartTotal(data.price);
}

// Step 4: Verify -- click rapidly through several items in the browser,
// confirm the final displayed total always matches the LAST item clicked,
// not whichever fetch happened to resolve first.

// Step 5: Prevention -- this exact pattern (a monotonically increasing
// request ID, or an AbortController to cancel the stale fetch outright)
// is the standard fix for any UI that fires a network request per user
// action faster than those requests are guaranteed to resolve in order.

Interview Prep

PSR Formula: Answer every question: Problem → Solution → Result. 45-90 seconds max.

Common Interview Questions

Q1. What is JavaScript, and why is it different from most other languages you'd learn first?

A: Problem: most languages need a compiler or a separate runtime installed before you can run anything. Solution: JavaScript runs natively in every browser with zero setup, and (via Node.js) on servers too — meaning the exact same language can build the frontend a user sees and the backend that serves it. Result: that's the practical reason it's usually the fastest language to get from zero to "something running in front of you," and why full-stack teams can hire for one language instead of two.

Q2. Explain the event loop. What actually happens when you call setTimeout(fn, 0)?

A: Problem: JavaScript is single-threaded, so how does it handle a timer, a network call, and a click all "at once" without freezing? Solution: slow or delayed work is handed off to the browser's Web APIs, not run inline — setTimeout registers a timer with the browser, and JavaScript's call stack keeps executing the rest of the current code immediately. Only once the timer fires and the call stack is completely empty does the event loop push the callback onto the stack to run. Result: setTimeout(fn, 0) does not run immediately — it runs after every currently queued synchronous statement, and after any pending microtasks (Promises), because microtasks are always drained before the next macrotask.

Q3. What's the difference between == and ===?

A: Problem: JavaScript will silently convert types to compare them if you let it, which causes real bugs ("" == 0 is true). Solution: == (loose equality) performs type coercion before comparing; === (strict equality) compares both value and type with no coercion. Result: default to === everywhere — it's predictable — and only reach for == in the rare, deliberate case where coercion is actually the intent (and even then, prefer to make that coercion explicit in code instead).

Q4. Explain closures with a real example.

A: Problem: how does an inner function keep access to a variable from an outer function that has already finished running? Solution: a closure is a function bundled with a reference to the variables from its outer scope at the time it was created — those variables stay alive as long as the inner function can still reference them, even after the outer function returns. Think of it as the inner function carrying a backpack of the variables it needs. Result: this is exactly the mechanism behind private counters, memoization, and event-handler factories — function makeCounter() { let count = 0; return () => ++count; } returns a function that keeps incrementing its own private count, with no other code able to touch it directly.

Q5. What does this refer to inside a regular function vs. an arrow function?

A: Problem: this in JavaScript is famously not fixed by where a function is defined — it depends on how it's called, which trips up almost everyone at first. Solution: in a regular function, this is set by the call site (obj.method() sets this to obj; a plain function call sets this to undefined in strict mode). An arrow function has no this of its own — it inherits this from the enclosing scope at the time it was written, permanently. Result: that's exactly why arrow functions are the standard fix for "this is undefined inside my callback" — using one inside a class method for an event handler or a setTimeout callback keeps this pointing at the class instance instead of losing it.

Q6. Promises vs. async/await — when would you use one over the other?

A: Problem: deeply chained .then() calls get hard to read, and error handling scattered across multiple .catch()s gets easy to miss. Solution: async/await is syntax sugar over Promises — it lets asynchronous code read top-to-bottom like synchronous code, with a single try/catch handling errors from multiple awaited steps. Promises directly (.then/.catch) are still the right tool for running several independent async operations concurrently via Promise.all. Result: use async/await for sequential logic that reads clearer linearly; reach for Promise.all/Promise.allSettled when operations don't depend on each other and you want them running in parallel, not one after another.

Q7. What is hoisting, and how does it differ between var, let, and const?

A: Problem: code can appear to reference a variable before its declaration line, which behaves differently depending on how it was declared. Solution: all three are "hoisted" (registered at the top of their scope during compilation), but var is initialized to undefined immediately (so reading it early gives undefined, not an error), while let and const are hoisted but left uninitialized — reading them before their declaration line throws a ReferenceError (the "temporal dead zone"). Result: this is the concrete reason modern code avoids var — let/const fail loudly and immediately if you accidentally use a variable before it's ready, instead of silently handing back undefined.

Q8. Explain prototypal inheritance — how does JavaScript's approach to objects differ from classical (class-based) inheritance?

A: Problem: JavaScript objects can share behavior without a rigid class hierarchy, which surprises developers coming from Java or C++. Solution: every object has an internal link ([[Prototype]], accessible via Object.getPrototypeOf or the __proto__ property) to another object it can borrow properties and methods from — if a property isn't found on the object itself, JavaScript walks up this prototype chain until it finds it or hits null. class syntax in modern JavaScript is syntax sugar over this same mechanism, not a separate system. Result: understanding the chain is what explains why adding a method to Array.prototype makes it available on every array instantly — they all share the same prototype object.

Q9. How do you handle errors in asynchronous JavaScript — what happens if you forget to catch a rejected Promise?

A: Problem: an uncaught (unhandled) Promise rejection doesn't crash async/await code the way a thrown synchronous error would necessarily be noticed — it can fail silently or surface only as a browser console warning. Solution: wrap await calls in try/catch, use .catch() on Promise chains, and in Node.js listen for the unhandledRejection process event as a safety net for anything that slips through. Result: treat every await as something that can throw — the same way you'd treat any I/O call in another language — rather than assuming the happy path is the only path.

Q10. What's your approach to debugging a real JavaScript bug you didn't write?

A: This is a genuinely personal question — answer with the Problem → Solution → Result structure on a real bug: what the symptom looked like, how you narrowed it down (console.log breadcrumbs, browser DevTools breakpoints, checking the Network tab for a bad API response, or reading a stack trace carefully instead of skimming it), and what the actual root cause turned out to be. Interviewers are listening for a real diagnostic process, not a memorized answer.

Official Resources

Try It (2 Minutes)

Open any web page, press F12 (or right-click → Inspect) to open DevTools, and click the Console tab. Type this and press Enter:

let clicks = 0;
document.addEventListener("click", () => {
  clicks++;
  console.log(`You've clicked ${clicks} time(s) on this page.`);
});

Now click anywhere on the page a few times. Watch the console count up in real time — no page reload, no server involved. That's the entire point of JavaScript in one line: the page just reacted to something that happened, live, in the browser.