JavaScript

You save a file, Prettier reformats it, and ESLint immediately flags an error on the line Prettier just touched. Both tools are configured, both are running, and they are fighting each other instead of helping you. The two tools do different jobs. The trouble is that both have opinions about one thing: how code looks on the page. What ESLint actually checks ESLint parses your code into an abstract syntax tree and runs rules against its structure. Most of its value comes from rules that catch real bugs: a variable that’s never defined, an unreachable return after another return, an unused import left over from a refactor, a duplicate object key that silently overwrites the first. These are semantic checks. ESLint is reading what the code does. ...

A chat component reconnects its WebSocket every time you type a letter into a search box that has nothing to do with chat. Another component re-renders in a loop until the tab freezes. A third logs its useEffect twice on mount, but only in development. None of these are React bugs. The first two are the dependency array doing exactly what you told it to, and the third is Strict Mode checking that your effect can clean up after itself. ...

<.+> against <b>bold</b> and <i>italic</i> doesn’t match <b>. It matches the whole string, from the first < to the very last >. Nothing is broken. That is what a greedy quantifier is supposed to do, and it is also the most common “regex is matching too much” bug there is. Once you know what the engine does while it reads your pattern, this bug and most of its relatives stop being mysteries. ...

Why Does any Lose the Type You Passed In? Type a parameter as any and TypeScript stops checking everything that comes out of the function: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compiles, crashes at runtime You know you passed an array of numbers. The compiler doesn’t, because any tells it to stop looking. n comes back as any, so calling a string method on a number compiles cleanly and throws TypeError: n.toUpperCase is not a function when it runs. ...

A scroll listener on window can fire hundreds of times during one swipe. Run getBoundingClientRect() on every card in a feed on each of those events and fifty images are enough to make the page stutter. The Intersection Observer API takes that check off the scroll path: you register which elements to watch, and the browser tells you when their visibility actually changes. How IntersectionObserver works An observer watches one or more target elements against a root (the viewport, by default) and calls a callback whenever a target crosses a visibility threshold. ...

What Is a Closure in JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter runs once, returns a function, and is done. The call is over and its stack frame is gone. Yet every call to counter() still reads and updates count, a variable declared inside a function that has already finished. count isn’t reset to 0, and it isn’t copied. It’s the same variable, still live, three calls later. ...

Run npm install on a project, then pnpm install against the same package.json, and you get two different node_modules trees and two different lockfiles. Add a teammate who reaches for Yarn and the repo can end up with three lockfiles in its history, each describing a slightly different dependency tree. All three tools read the same package.json and pull from the same npm registry. They disagree about what to put on disk. ...

Wrap a fetch() call in try/catch, hit an endpoint that answers with a 404, and the catch block never runs. The promise resolves. res.json() parses whatever body the server sent back, often an error payload like {"error": "user not found"}, and the rest of the function treats it as the record it asked for. No exception and no console warning. The bad data moves downstream until something else breaks on it. ...

A search box that fires a network request on every keystroke sends five requests for “redis”, and four of them are stale before the response comes back. A scroll handler that recalculates layout runs hundreds of times a second and makes the page stutter. Same problem in both cases: the DOM event fires far more often than the handler needs to run. Debounce and throttle fix it in two different ways. ...

A login endpoint hands back a JWT, and you have three places to put it: a cookie, localStorage, or sessionStorage. Pick the wrong one and either an XSS bug walks off with the token, or the token never reaches your API. All three store strings in the browser. They differ on who can read them, how long they last, and whether the server ever sees them. How localStorage, sessionStorage and cookies differ localStorage and sessionStorage are the same API, the Storage interface: setItem, getItem, removeItem, clear, string keys and string values. The difference is lifetime. localStorage survives closing the browser and rebooting the machine, and stays until something clears it. Safari is the exception: with tracking prevention on, it deletes script-written storage for a site the user hasn’t interacted with in seven days. sessionStorage belongs to one tab and dies when that tab closes. Type the same URL into a second tab and you get a fresh, empty sessionStorage; only “Duplicate tab” copies it over. ...