Web Development

You write .sidebar .card { color: blue; }, load the page, and the card is still red from a rule you added an hour earlier: .card { color: red; }. Your new rule comes later in the file. It still loses. The browser compares the two selectors with a fixed point system, and .sidebar .card scores higher than .card no matter which one you wrote last. That point system is specificity. Once you can calculate it on sight, “why isn’t my CSS applying” becomes arithmetic. It has nothing to do with layout: Grid or Flexbox decides where an element sits, and specificity decides which rule sets its color or size when two rules disagree. ...

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. ...

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. ...

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. ...

You’re building a dashboard: a header, a sidebar, a main content area, a footer. You reach for Flexbox because that’s the layout tool you know, and twenty minutes later you’ve got three nested display: flex containers, a sidebar that won’t hold its width without a magic number, and a footer that floats halfway up the page when the content is short. None of that is a Flexbox bug. You’re using a one-dimensional tool on a two-dimensional problem. ...

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. ...

Your frontend runs on http://localhost:5173, your API on http://localhost:4000, and the fetch call that worked fine in Postman fails in the browser with a wall of red text: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Your server may well have handled that request and returned a 200. The browser refused to hand the response to your JavaScript. ...