I'm a frontend dev

Turn off the internet, refresh the page - and it still works. Behind that is the Service Worker: a separate script that steps between the page and the network and intercepts every request for a file before it reaches the server. It decides whether to answer from the network, from its own cache (Cache API), or on its own terms - and from that one decision come all the caching strategies, offline mode, and the classic 'after a deploy the user sees the old version' trap.

Take a single style.css file and follow its day on a live site: first the browser downloads it, then it serves it from memory without asking the server, then it asks the server whether its copy is still current and usually gets just a confirmation instead of the whole file, and after you deploy a new version it downloads it again. That one story is all of HTTP caching - Cache-Control, ETag, 304, and stale-while-revalidate.

The four rendering strategies aren't a menu you pick once - they're a per-route decision about where the HTML is built and when. Each has a different generation moment, a different TTFB, a different infrastructure cost, and a different 'fresh data vs speed' trade-off. I unpack the mechanics of all four and show when each one makes sense.

The browser's same-origin policy (SOP) blocks JavaScript on one page from reading data from another domain - unless the server explicitly allows it through CORS. This post walks through how that server-side permission mechanism works, why you sometimes see a preflight OPTIONS request, and why you sometimes don't.

Every DOM element goes through five stages before you see it, regardless of the framework. Some styles trigger only the last stage; others trigger all five. That's the difference in animation cost - from a single composite step to a full reflow.

Every object you create in JS takes up space in computer memory. JavaScript removes unused objects automatically, making room for new ones. But the engine sometimes can't tell that a given object is no longer needed - and then the object stays in memory. That's how memory leaks happen. A post about how this cleanup works (mark-and-sweep), the most common pitfalls, and when you actually reach for WeakMap or WeakRef.

JavaScript has one thread, but it can wait for many things at once. The trick is the event loop - a simple algorithm that picks what to run when the stack is empty. Microtasks beat tasks, render fits between cycles, and execution order starts to make sense.

this in JS only looks weird because people look in the wrong place. Its value is decided at the moment of the call - and there are only four rules the call can pick from, plus arrow functions, which break out of the whole system.

async/await looks like magic: you write await fetch(...), get the result on the next line, and the thread doesn't block for a single moment. Underneath there's no magic - just an old pattern of generator + Promise + auto-runner, hidden under the new keywords async and await.

A regular JS function runs top to bottom, returns a value, and disappears from memory. A generator is different - marked with function*, it pauses on every yield, hands a value out, and waits for the next .next(). A small change in the runtime, but it's the one that powers on-demand sequences and lives under the hood of async/await.

The textbook explanation says declarations 'move to the top' of the code. The ECMA-262 spec doesn't define hoisting as a mechanism at all, and let behaves as if the rule didn't apply to it. So what really happens before your code runs, and why does the TDZ look exactly the way it does?

Every line of JS has to run somewhere, every variable has to live somewhere, every function call has to come back to where it was called from. The engine keeps all of this in two structures - the execution context (where am I now) and the call stack (where did I come from). They're what closure, this, and async are all built on.

The new keyword in JS looks short, but behind it the engine runs four steps at once - creates an empty object, hooks up this, links it to the function's prototype, and returns the whole object back. Without new, you'd write the same thing by hand with Object.create.

Async in JS without Promises is callback hell - the code has no way to refer to the in-flight operation, and error handling sits separately inside every callback. A Promise stands in for a value that will arrive later - the code reads flat, and you catch errors in one place.

Functions in JS usually disappear together with their local memory. Closure breaks that rule - and it is the foundation for the module pattern, memoization, asynchronous JS, and private state without classes.