We found 21 results for "javascript" keyword
Same-origin policy and CORS: who can read data from another server
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.
typeof vs instanceof - two ways to check a type in JS
JavaScript has two core operators for checking what type a value is, and each answers a different question. typeof returns one of 8 strings and has known gotchas (null, arrays). instanceof walks the prototype chain and fails for objects from an embedded <iframe>. A note on when to use which, and why arrays have a dedicated Array.isArray.
Property descriptors and getters/setters in JavaScript
Every object property in JS carries 4 flags under the hood (writable, enumerable, configurable, plus value or get/set). You rarely think about them - until something odd happens: an assignment doesn't change the value, delete doesn't remove the field, for...in skips the property. A note on what property descriptors are, how getters/setters work, and why Object.defineProperty has different defaults than an object literal.
Garbage Collection in JavaScript - how the engine cleans up after your code
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.
Event Loop in JavaScript - how the engine decides what runs next
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.
async/await in JavaScript - how a function can wait without blocking the thread
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.
Generators in JavaScript - a function that knows how to pause
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.
Hoisting in JavaScript - what the metaphor really means
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?
Execution Context and Call Stack - how JavaScript runs your code
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.
new (and this) in JavaScript - what the keyword actually does
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.
Promises in JavaScript - from callback hell to the microtask queue
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.
