Forem: Samaresh Das

Stop memorizing JS — think in execution context

Samaresh Das — Thu, 23 Apr 2026 09:00:55 +0000

Forget remembering JavaScript syntax; it's a crutch.

What if I told you that the key to truly understanding JavaScript isn't memorizing endless functions and methods, but grasping how the code actually runs? This article is about shifting your focus from rote learning to thinking about JavaScript's execution context.

Every time your JavaScript code runs, the engine creates an "execution context." Think of it as a mini-environment where your code gets evaluated. There are two main types: the Global Execution Context (the default one for your entire script) and the Function Execution Context (created each time a function is called).

Within each context, two crucial things happen: the creation phase and the execution phase. During creation, the engine sets up the Variable Environment (where var, let, const, and function declarations are stored) and the this binding. It also creates the scope chain.

Then comes the execution phase, where the actual JavaScript code is run line by line. This is where let and const declarations are put into a "temporal dead zone" until their declaration is reached, while var variables are initialized with undefined.

Let's look at a simple example.

console.log(a); // undefined
var a = 10;
console.log(a); // 10

// sayHello(); // This would throw an error
// let sayHello = () => {
//   console.log("Hello!");
// };

The first console.log(a) outputs undefined because var a is hoisted to the top of its scope and initialized with undefined during the creation phase, before the execution phase reaches var a = 10;. If a were declared with let or const, the first console.log would actually throw a ReferenceError because of the temporal dead zone.

Understanding execution context helps untangle confusing behavior, especially with asynchronous operations and closures. It's the "why" behind what your code is doing.

For me, this mindset shift was a game-changer. It's what allows me to build complex websites and apps as a freelancer. If you're ever looking for someone to build your next web project, you can check out my portfolio here: https://hire-sam.vercel.app/

The real superpower in JavaScript isn't memorization, it's understanding the runtime.

Follow for more dev content

JS concepts I understood only after building real things

Samaresh Das — Wed, 22 Apr 2026 09:00:53 +0000

The tutorials never told you the real story about these JavaScript concepts.

We've all been there, right? You've read the docs, watched countless videos, and felt like you got a JavaScript concept. Then, you try to apply it to a real-world project, and suddenly, it's like learning it for the first time all over again. That's been my journey as a freelancer building websites, and these are the JS concepts that really clicked only after getting my hands dirty with actual client work.

`this` Keyword: The Elusive Chameleon

The this keyword is probably the biggest culprit. In tutorials, it often seems straightforward, tied neatly to the object it's called upon. But in the wild, this is a shape-shifter. Its value depends entirely on how a function is invoked. Strict mode, arrow functions, bind, call, apply – these all change its behavior in ways that will make your head spin until you've debugged a few messy callbacks or event handlers.

// Tutorial version: "See? it's the object!"
const obj = {
  name: "MyObject",
  greet: function() {
    console.log(`Hello from ${this.name}`);
  }
};
obj.greet(); // "Hello from MyObject"

// Real-world chaos:
function Person(name) {
  this.name = name;
  this.sayHi = function() {
    setTimeout(function() {
      // 'this' here is often window or undefined in strict mode!
      console.log(`Hi, I'm ${this.name}`);
    }, 100);
  };
}
const person = new Person("Sam");
person.sayHi(); // Might not work as expected!

Asynchronous JavaScript: Beyond `async/await` Syntax

Sure, async/await makes asynchronous code look synchronous, which is a huge win. But understanding what's happening under the hood with the event loop, the microtask queue, and the macrotask queue is crucial for performance optimization and preventing dreaded race conditions. It’s not just about writing clean code; it's about writing predictable code.

Think about handling multiple API requests where the order matters, or dealing with user input that triggers background operations. Without a grasp of the event loop, debugging those situations feels like trying to catch smoke.

Closures: More Than Just Scope Holding

Closures are often explained as functions remembering their parent scope. That's technically true, but the real power and utility become apparent when you build things like:

Data encapsulation: Creating private variables that can't be directly accessed or modified from outside.
Currying and partial application: Creating specialized versions of functions.
Event handlers that maintain state: Imagine clicking a button multiple times and having it remember how many times it's been clicked without needing a global variable.

function createCounter() {
  let count = 0; // This variable is "closed over" by the returned function
  return function() {
    count++;
    console.log(count);
  };
}

const counter1 = createCounter();
counter1(); // 1
counter1(); // 2

const counter2 = createCounter();
counter2(); // 1 (independent count)

Building real features, whether for a small business website or a complex web application, forces you to confront these concepts not as academic exercises, but as fundamental tools for problem-solving. If you’re looking for someone to help bring your web projects to life, you can check out what I do at https://hire-sam.vercel.app/.

The takeaway? Don't just learn the syntax; understand the behavior and the implications in a live application. That's where true mastery lies.

Follow for more dev content.

javascript #webdevelopment #programming #freelancer

Why interviews expose your JS gaps

Samaresh Das — Tue, 21 Apr 2026 09:00:59 +0000

Interviews are not trying to trick you; they're just a highly effective JavaScript lie detector.

You might be crushing it daily, shipping features, and building fantastic applications with all the modern frameworks. But then an interview question about this context or closures drops, and suddenly you feel like you've never written a line of JavaScript in your life. This isn't about failing; it's about exposing the difference between "getting it done" and "understanding what's happening."

The reason these "gap-exposing" questions pop up is because daily development often abstracts away the core mechanics. We rely on frameworks and libraries that handle much of the underlying complexity. While efficient, this can lead to a shallower understanding of the language's foundational principles.

Let's take this for example. You use it all the time in React components or class methods, but what happens when you pull a method out of its object context?

const user = {
  name: 'Alex',
  greet: function() {
    console.log(`Hey, I'm ${this.name}!`);
  }
};

const sayHello = user.greet;
sayHello(); // What does this print?
setTimeout(user.greet, 100); // And this?

In a daily dev scenario, you might only ever call user.greet(). But an interviewer wants to see if you understand how this is dynamically bound based on how a function is called, not where it's defined.

Another classic is closures. We use them constantly, often without explicitly thinking about them. Think about event listeners, higher-order functions like map or filter, or even just functions that return other functions.

function createCounter() {
  let count = 0; // 'count' is captured by the inner function
  return function increment() {
    count++;
    return count;
  };
}

const myCounter = createCounter();
console.log(myCounter()); // 1
console.log(myCounter()); // 2

Understanding closures helps you grasp concepts like private variables, module patterns, and how asynchronous operations retain their context. It’s fundamental.

The takeaway is simple: interviews often probe the bedrock of JavaScript because a solid foundation makes you adaptable. It means you can debug tricky issues, pick up new frameworks faster, and write more robust code, even when the abstractions fail or you need to dive deep. It’s not about memorizing trivia, but understanding the "why" behind the magic. ✨

Building websites for clients as a freelancer, I've noticed a pattern: the deeper your JS fundamentals, the smoother the sailing on tricky projects. If you need a hand with a web project, you can always check out my work here: https://hire-sam.vercel.app/

Share this with your dev friends who dread JS interviews!

javascript #webdev #frontend #career #interview

Using AI to understand JS, not copy code

Samaresh Das — Mon, 20 Apr 2026 11:25:46 +0000

Blindly copying AI-generated code is the fastest way to not learn JavaScript.

We all love the convenience of AI tools like ChatGPT or GitHub Copilot for a quick snippet. But relying on them to just churn out solutions can seriously stunt your growth as a developer. Instead of using AI as a crutch, let's turn it into a super-powered tutor for genuinely understanding JavaScript.

The real magic happens when you ask "why" and "how," not just "what." Think of AI as your personal rubber duck, but one that can actually talk back and provide analogies. It's about shifting from 'fix this for me' to 'explain this to me.'

Let's say you're wrestling with the infamous this keyword in JavaScript. Instead of asking for code that uses this, ask the AI to explain its behavior in different contexts.

// Global context
console.log(this);

// Function context
function sayHello() {
  console.log(this);
}
sayHello();

// Method context
const person = {
  name: 'Sam',
  greet() {
    console.log(this.name);
  }
};
person.greet();

You could prompt: "Explain the this keyword in JavaScript for global scope, a regular function, and a method on an object. Provide a brief code example for each scenario." The AI's explanation will help clarify why this behaves the way it does, rather than just seeing it in action.

Another common scenario: debugging. Rather than pasting an error and asking the AI to fix it, paste your broken code along with the error message and ask: "I'm getting TypeError: Cannot read properties of undefined (reading 'name') with this code. Can you explain why this error is happening and what it usually indicates in JavaScript?"

const user = {
  id: 1,
  details: {
    // name: 'Alice' - intentionally missing
  }
};

console.log(user.details.name); // TypeError

This forces the AI to break down the error message and explain the underlying concept (e.g., trying to access a property on an undefined object), which is far more valuable for your long-term learning.

Here are a few ways to leverage AI for understanding:

Ask for analogies: "Explain closures in JavaScript using a real-world analogy."
Request alternative solutions: "I wrote this for loop. Can you show me a more modern or functional way to achieve the same result using array methods, and explain the benefits?"
Deconstruct complex code: Paste a library example you don't fully grasp and ask the AI to explain each part step-by-step.

Ultimately, understanding the 'why' behind the code helps me build much better, more maintainable websites for my clients. It's a principle I apply in all my freelance projects. If you're ever looking for a dev who cares about the fundamentals, you can find more about what I do here: https://hire-sam.vercel.app/

Think of AI not as your code monkey, but as your highly knowledgeable (and sometimes a bit quirky) study buddy 🤔. Use it to expand your brain, not just your codebase.

Save this if useful!

javascript #ai #webdevelopment #codingtips #devcommunity

Why closures finally clicked for me after 2 years

Samaresh Das — Sun, 19 Apr 2026 20:12:54 +0000

Closures aren't magic, but for two years, I genuinely thought they were dark sorcery.

If you've ever felt utterly baffled by how a function remembers variables from its parent scope long after the parent has returned, you're definitely not alone. This is about that "aha!" moment when JavaScript closures stopped being an abstract concept and started making actual sense to me.

My journey was a mix of copying code, using frameworks that subtly abstracted them, and nodding vaguely when someone mentioned "lexical environment." I knew they existed, but truly understanding their power felt like trying to catch smoke. I pictured some kind of JavaScript ghost holding onto variables. 😂

The core idea, once it finally clicked, is surprisingly simple: A closure is when a function "remembers" its lexical environment even when that function is executed outside its original scope. Think of it as a function carrying a little backpack of variables from where it was created, a memory of its birthplace. This "lexical environment" just means the variables and functions that were available where the function was declared.

Let's look at a classic example that finally made it click for me – a simple counter function:

function createCounter() {
  let count = 0; // This variable is part of createCounter's lexical environment
  return function() { // This inner function forms a closure
    count++;
    return count;
  };
}

const myCounter = createCounter();
console.log(myCounter()); // Output: 1
console.log(myCounter()); // Output: 2

Notice how myCounter continues to increment count, even though createCounter() has already finished executing and its execution context has technically "popped off the stack." The inner function returned by createCounter "closed over" the count variable. It keeps a persistent reference to it, allowing its value to be maintained across multiple calls.

Why is this seemingly abstract concept incredibly useful in web development?

Data Privacy/Encapsulation: You can create "private" variables that only the inner function can access, protecting them from external modification and preventing global scope pollution.
Factory Functions: Closures let you generate custom functions with pre-configured settings, making your code more flexible and reusable. For instance, a function that creates different types of validators.
Stateful Functions & Event Handlers: They're crucial for remembering context for callbacks in asynchronous operations or when attaching event listeners. Each event handler can have its own persistent data.

Another quick example using a "factory" for event listeners – a common pattern (though frameworks often abstract this):

function createButtonClickHandler(buttonId) {
  // This inner function closes over 'buttonId'
  return function() {
    console.log(`Button ${buttonId} was clicked!`);
    // We can now perform actions specific to this buttonId
  };
}

// Imagine having buttons with IDs 'saveBtn', 'deleteBtn'
const saveHandler = createButtonClickHandler('saveBtn');
const deleteHandler = createButtonClickHandler('deleteBtn');

// In a real app, you'd attach these to actual DOM elements:
// document.getElementById('saveBtn').addEventListener('click', saveHandler);

// Simulating clicks for demonstration:
saveHandler();   // Output: "Button saveBtn was clicked!"
deleteHandler(); // Output: "Button deleteBtn was clicked!"

Each handler function remembers its own buttonId from when it was created. That's the closure doing its job, providing isolated state for each callback.

The single biggest takeaway is that functions don't just execute code; they also remember the environment in which they were born. This memory is what a closure is all about.

Understanding these core JavaScript concepts like closures isn't just academic; it directly translates into writing more robust, maintainable, and efficient code for the websites I build. It's especially useful when architecting complex client-side applications or custom utility functions for freelance projects. If you need a hand bringing a web project to life, you can learn more about my work here: https://hire-sam.vercel.app/

Save this if useful! 💡

javascript #webdev #frontend #programming