Most people begin JavaScript by building things. You wire up a button, fetch some data, and watch the DOM change. Then the abstractions leak. Bugs surface that make no sense: variables exist before their declarations, functions remember variables they should not have access to, and the this keyword points at the window, a button, or nothing at all. That is usually the moment you realize you need to look under the hood and understand what the engine is actually doing.

Execution Context: The Two-Phase Setup

When the JavaScript engine in your browser or Node.js encounters a script, it does not simply read the file from top to bottom like a person scanning a page. Instead, it builds an execution context, a container that holds everything needed to run a particular chunk of code. Every execution context moves through two distinct phases.

Memory Creation Phase. During this initial pass, the engine scans the entire scope and allocates memory for every variable and function declaration it finds. If it sees a var, it reserves space and stores undefined as a placeholder. If it sees a function declaration, it stores the complete function body. This is why a function declared with the traditional function keyword can be called from lines that appear earlier in the same scope. The engine already knows about it before it starts executing.

Code Execution Phase. Now the engine runs your code line by line. Assignments happen here. Expressions are evaluated. Functions are invoked. If you wrote var name = "Alice";, the placeholder from phase one finally gets replaced with the string. Understanding this two-pass behavior clears up a surprising amount of confusion. The engine is not sloppy; it is following a strict setup routine.

Variables and the Temporal Dead Zone

Choosing between var, let, and const is not just a stylistic preference. var is function-scoped, which means it ignores braces entirely. Declare it inside an if block, and it leaks outward. That behavior might have made sense in early JavaScript, but in modern applications it causes real maintenance headaches. let and const are block-scoped. They respect curly braces and disappear when the block ends.

There is also a subtle but crucial difference in how hoisting treats them. var declarations are hoisted and immediately initialized with undefined. let and const are technically hoisted too; the engine knows they exist before it reaches the declaration line. But they are not initialized. They sit in a limbo called the temporal dead zone. If you try to read them before the declaration line executes, you get a hard ReferenceError rather than a sneaky undefined. That crash is actually helpful. It prevents logic from proceeding on top of uninitialized data.

Lexical Scope and Closures

Scope answers a simple question: where can I access this variable? JavaScript uses lexical scope, which means a function's access rights are decided by where it was physically written in the source code, not by where it ends up being called. If you define a function inside another function, the inner one can reach outward to read variables from its parent. The outer function cannot reach inward. This relationship is static. You could pass that inner function across modules, store it in a global variable, and call it from an entirely different file. It still remembers the variables from the scope where it was born.

That behavior naturally produces closures. A closure forms when an inner function keeps a reference to a variable from its outer scope. Even after the outer function finishes executing and its local variables should have been garbage collected, JavaScript preserves them in memory because the inner function still needs them. The inner function carries its surrounding environment with it.

This is not merely an academic detail. Closures give you a practical way to create private state in a language that lacks explicit access modifiers.

function makeCounter() {
  let count = 0;
  return function() {
    count = count + 1;
    return count;
  };
}

const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2

Here, count is hidden. Nothing outside the returned function can reset it or read it directly. That is a private variable built from scope mechanics alone.

Hoisting in Practice

আমরা প্রায়ই শুনে থাকি যে JavaScript "ডিক্লারেশনগুলোকে উপরে নিয়ে যায়" (moves declarations to the top)। এটি একটি দরকারী মানসিক ধারণা (mental model), কিন্তু কোড আসলে পুনরায় লেখা হয় না। মেমরি তৈরির পর্যায়ে (memory creation phase), ইঞ্জিন এক্সিকিউশন শুরু হওয়ার আগেই কেবল ডিক্লারেশনগুলো রেজিস্টার করে। var x = 5; এর মতো একটি স্টেটমেন্ট এমনভাবে কাজ করে যেন ডিক্লারেশন এবং ইনিশিয়ালাইজেশন আলাদা। var x; ডিক্লারেশনটি দ্রুত প্রসেস করা হয় এবং undefined হিসেবে ইনিশিয়ালাইজ করা হয়। আর x = 5; অ্যাসাইনমেন্টটি ঠিক সেখানেই থাকে যেখানে আপনি লিখেছেন এবং এক্সিকিউশন ফেজে রান করে।

এর কারণে, var অপ্রত্যাশিত ফলাফল দিতে পারে। একটি ফাংশনের একদম শুরুতে ব্যবহৃত একটি ভেরিয়েবল undefined দেখাতে পারে, যদিও ফাংশনের একদম শেষে একটি বড় অ্যাসাইনমেন্ট রয়েছে। let এবং const ব্যবহার করলে এই ধরণের ভুল করার ঝুঁকি (foot-gun) দূর হয়, কারণ টেম্পোরাল ডেড জোন (temporal dead zone) আপনাকে আপনার ডিক্লারেশনগুলো ব্যবহারের উপরে রাখতে বাধ্য করে।

কীভাবে this তার মান পায়

যদি এক্সিকিউশন কনটেক্সট এবং স্কোপ নির্ধারণ করে ভেরিয়েবল কোথায় থাকবে, তবে this নির্ধারণ করে কোন অবজেক্টটি বর্তমানে দায়িত্বে রয়েছে। লেক্সিক্যাল ভেরিয়েবলের মতো this কোথায় একটি ফাংশন লেখা হয়েছে তা দিয়ে নির্ধারিত হয় না। এটি সম্পূর্ণভাবে নির্ধারিত হয় ফাংশনটি কীভাবে কল করা হচ্ছে তার ওপর।

Default binding ঘটে যখন আপনি একটি সাধারণ, স্বতন্ত্র (standalone) ফাংশন কল করেন। নন-স্ট্রিক্ট মোডে, this গ্লোবাল অবজেক্টে ফিরে যায়। ব্রাউজারে এটি হলো window। কোনো কনটেক্সট ছাড়াই একটি ফাংশন কল করলে, আপনি অজান্তেই গ্লোবাল স্টেট পরিবর্তন করে ফেলতে পারেন।

Implicit binding ঘটে যখন আপনি একটি অবজেক্টের মেথড হিসেবে একটি ফাংশন কল করেন। আপনি যদি user.sayName() লেখেন, তবে ডট (.) নিঃশব্দে ইঞ্জিনকে নির্দেশ দেয় যে ওই কলের সময় this হবে user। ফাংশনটি কোথায় ডিফাইন করা হয়েছে তার চেয়ে এটি কোথায় কল করা হচ্ছে তা বেশি গুরুত্বপূর্ণ।

Explicit binding আপনাকে ম্যানুয়ালি সবকিছু ওভাররাইড করার সুযোগ দেয়। call() এবং apply() একটি ফাংশনকে তাৎক্ষণিকভাবে কল করে এবং একই সাথে this-কে আপনার দেওয়া একটি নির্দিষ্ট অবজেক্টে বাধ্য করে। এদের মধ্যে একমাত্র পার্থক্য হলো আর্গুমেন্ট পাস করার পদ্ধতি: call কমা দিয়ে আলাদা করা একটি তালিকা নেয়, আর apply একটি অ্যারে নেয়। bind() ভিন্নভাবে কাজ করে। এটি ফাংশনটিকে সাথে সাথে কল করে না। পরিবর্তে, এটি একটি নতুন ফাংশন রিটার্ন করে যেখানে this স্থায়ীভাবে আপনার দেওয়া মানের সাথে যুক্ত থাকে। এটি কলব্যাকগুলোর জন্য অত্যন্ত মূল্যবান, যা অন্যথায় তাদের কনটেক্সট হারিয়ে ফেলতে পারে।

New binding তখন কাজ করে যখন আপনি একটি ফাংশন কলের আগে new কিওয়ার্ড ব্যবহার করেন। ইঞ্জিন একটি সম্পূর্ণ নতুন খালি অবজেক্ট তৈরি করে, এর প্রোটোটাইপ লিঙ্কেজ সেট করে এবং কনস্ট্রাক্টরের ভেতরের this-কে সেই নতুন ইনস্ট্যান্সের দিকে নির্দেশ করে।

দীর্ঘস্থায়ী কোড লেখা

মেকানিক্স বোঝা হলো দক্ষতার অর্ধেক। বাকি অর্ধেক হলো এমন কোড লেখা যা ছয় মাস পরেও মানুষ পড়তে পারবে।

DRY (Don't Repeat Yourself) শুনতে খুব সহজ মনে হলেও এটি প্রতিনিয়ত লঙ্ঘিত হয়। আপনি যদি দেখেন যে আপনি তিনটি ভিন্ন ফাইলে একই ভ্যালিডেশন লজিক বা API কল প্যাটার্ন লিখছেন, তবে সেটি আলাদা করে ফেলুন। একটি ফাংশন লিখুন। তথ্যের একটি মাত্র উৎস (one source of truth) থাকার মানে হলো রিকোয়ারমেন্ট পরিবর্তন হলে কেবল এক জায়গাতেই আপডেট করতে হবে, যা আপনার অনেক সময় বাঁচাবে।

KISS (Keep It Simple, Stupid) হলো অহংবোধের বিরুদ্ধে একটি প্রতিরক্ষা। নেস্টেড টারনারি (Nested ternaries) এবং ওয়ান-লাইনার ক্লোজার (one-liner closures) দেখতে বুদ্ধিদীপ্ত মনে হতে পারে, কিন্তু ডিবাগিং করার সময় এগুলো ঘণ্টার পর ঘণ্টা সময় নষ্ট করে। আমি আগে যে ক্লোজার প্যাটার্নটি দেখিয়েছি তা শক্তিশালী, তবুও কেবল আপনি পারেন বলেই পাঁচ লেভেল পর্যন্ত নেস্টিং করা একটি ভুল। সহজ কোড টিমের সদস্য পরিবর্তন, প্রোডাকশন ইনসিডেন্ট এবং মাঝরাতের সেই অ্যালার্টগুলোকেও সামলে নিতে পারে, যখন কোনো কিছু ভেঙে পড়ে এবং কেউ মনে করতে পারে না কেন তা হলো।

আসল প্রাপ্তি

এক্সিকিউশন নিয়ে পড়াশোনা করা