Many JavaScript bugs come from variables not being where you think they are. If you have ever logged a value in a callback and seen something unexpected, or watched all your button handlers print the same index, you have met lexical scope.<\/p>\n\n\n\n
I keep hearing that \u201cJS has lexical scope\u201d and that it explains closures, var vs let behavior, and those loop bugs where every click handler logs the same number. What is lexical scope in JavaScript, how does it affect variable access and closures, and what are the best practices to avoid surprises? Code examples would be great.<\/em><\/p>\n\n\n\n Lexical scope is the rule that determines where variables are accessible based on where they are written in the source code. JavaScript decides scope at parse time<\/em>, not at runtime, using nested blocks and functions to form a scope chain. A function can read variables from its own scope and any outer scopes, but not from inner scopes it does not contain.<\/p>\n\n\n\n A closure is a function bundled with references to its surrounding scope. The closed-over variables continue to live as long as the function does.<\/p>\n\n\n Frontend code that wires event handlers, fetches data, or builds media URLs relies on closures to carry context. For example, when building dynamic image URLs for delivery, lexical scope lets you encapsulate parameters while returning a tiny helper.<\/p>\n\n\n If you are rendering images in markup, see this quick refresher on the HTML image tag<\/a>. When delivering media at scale, understanding hosting basics helps pick the right architecture and cache strategy, as covered in Understanding image hosting for websites<\/a>. <\/p>\n\n\n\nAnswer:<\/h2>\n\n\n\n
Core Idea<\/h3>\n\n\n\n
\n
Example: Nested Scopes<\/h3>\n\n\n
const<\/span> greeting = \"Hi\"<\/span>;\n\nfunction<\/span> outer<\/span>(<\/span>) <\/span>{\n\u00a0 const<\/span> name = \"Ava\"<\/span>;\n\u00a0 function<\/span> inner<\/span>(<\/span>) <\/span>{\n\u00a0 \u00a0 console<\/span>.log(greeting, name); \/\/ \"Hi Ava\"<\/span>\n\u00a0 }\n\u00a0 inner();\n}\n\nouter();\n\/\/ inner(); \/\/ ReferenceError - inner is not in this scope<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nvar vs. let\/const and Block Scope<\/h3>\n\n\n\n
var<\/code> is function-scoped. let<\/code> and const<\/code> are block-scoped. This difference explains the infamous loop-handler bug:<\/p>\n\n\n\/\/ Problem: var leaks one binding across the loop<\/span>\nconst<\/span> buttons = document<\/span>.querySelectorAll(\"button\"<\/span>);\nfor<\/span> (var<\/span> i = 0<\/span>; i < buttons.length; i++) {\n\u00a0 buttons[i].addEventListener(\"click\"<\/span>, () => console<\/span>.log(i));\n}\n\/\/ All handlers print buttons.length<\/span>\n\n\/\/ Fix 1: use let to create a new binding per iteration<\/span>\nfor<\/span> (let<\/span> j = 0<\/span>; j < buttons.length; j++) {\n\u00a0 buttons[j].addEventListener(\"click\"<\/span>, () => console<\/span>.log(j));\n}\n\n\/\/ Fix 2: IIFE creates a new scope for each i<\/span>\nfor<\/span> (var<\/span> k = 0<\/span>; k < buttons.length; k++) {\n\u00a0 ((n<\/span>) =><\/span> buttons[n].addEventListener(\"click\"<\/span>, () => console<\/span>.log(n)))(k);\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nClosures in 1 Minute<\/h3>\n\n\n\n
function<\/span> makeCounter<\/span>(start = 0<\/span><\/span>) <\/span>{\n\u00a0 let<\/span> count = start;\u00a0 \u00a0 \u00a0 \u00a0 \/\/ captured by the inner function<\/span>\n\u00a0 return<\/span> ()<\/span> =><\/span> ++count; \u00a0 \u00a0 \/\/ closure<\/span>\n}\n\nconst<\/span> next = makeCounter(10<\/span>);\nconsole<\/span>.log(next()); \/\/ 11<\/span>\nconsole<\/span>.log(next()); \/\/ 12<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nHoisting and the Temporal Dead Zone<\/h3>\n\n\n\n
\n
var<\/code> are hoisted. The variable exists before its line of code, but var initializes to undefined.<\/li>\n\n\n\nlet<\/code> and const<\/code> are hoisted too, but they are not accessible before their declaration line, which means accessing them early triggers a ReferenceError<\/code>. This period is the temporal dead zone.<\/li>\n<\/ul>\n\n\n\nCommon Pitfalls and Quick Fixes<\/h3>\n\n\n\n
\n
let<\/code> in loops or capture values in a new function scope.<\/li>\n\n\n\nWhere This Matters in Real Apps<\/h3>\n\n\n\n
\/\/ Simple Cloudinary-style URL factory using lexical scope<\/span>\nfunction<\/span> makeImageUrl<\/span>({ cloudName, publicId }<\/span>) <\/span>{\n\u00a0 const<\/span> base = `https:\/\/res.cloudinary.com\/${cloudName}<\/span>\/image\/upload\/`<\/span>;\n\u00a0 return<\/span> (transforms<\/span>) =><\/span> `${base}<\/span>${transforms}<\/span>\/${publicId}<\/span>`<\/span>;\n}\n\nconst<\/span> toWebP600 = makeImageUrl({ cloudName<\/span>: \"demo\"<\/span>, publicId<\/span>: \"sample.jpg\"<\/span> });\nconst<\/span> url = toWebP600(\"c_fill,w_600,f_webp\"<\/span>);\n\/\/ Use with <img src=\"url\"> or your framework's image component<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nDebugging Tips<\/h3>\n\n\n\n
\n
TL;DR<\/h2>\n\n\n\n
\n
Learn More<\/h2>\n\n\n\n