DEV Community: Priyanshu Jha

[Boost]

Priyanshu Jha — Fri, 12 Jun 2026 09:18:57 +0000

Priyanshu Jha

Jun 9

Execution Context and Object Context - Clarifying `window` , `global` and `this` in JavaScript.

#javascript #beginners #oop #tutorial

8 min read

Execution Context and Object Context - Clarifying `window` , `global` and `this` in JavaScript.

Priyanshu Jha — Tue, 09 Jun 2026 13:14:17 +0000

Introduction - This article is for clarity

This article is created to give you a grassroots explanation of what execution context is in JS how it works. What is the relationship between this, JS Objects and an Execution Context.
If you are a JavaScript developer , or study/know JS , it is not surprising to be confused by this. That confusion may stem from a hazy understanding of execution context and how it interacts with this.

Reading this post should give you the clarity you need to understand about what execution context, call stack, functions, objects, object context, this keyword, window and global are, how they relate and work with each other, and their differences.
We will also ask a fundamental question - why objects don't have an execution context of their own and why this points to them anyway in execution context.

Note that this is not a complete deep-dive into the ECMAScript spec. But rather a basic overview meant to give you an idea and think with clarity about this in JavaScript.

If you are a JavaScript developer, or like learning things from grassroot basics you may enjoy this article.

What is an Execution Context?

To explain simply, understand Execution Context as a metadata wrapper/container for a block of code that contains all the necessary data to execute that block of code.
It holds:

Variables, arguments, and functions inside that function.
Rules for how to look things up (scope).

We call execution context metadata because:

It describes and governs how the other code behaves (variables, this, scoping rules).
This is the internal, behind-the-scenes mechanism of the engine.
It exists for the engine's bookkeeping, not for direct programmer manipulation.

There are three main types of execution context:

Global Execution Context: The default, base context. It is created when a script first starts running. It creates a global object (window in browsers, global in Node.js) and sets this to that global object.
Function Execution Context: A brand new context is created every time a function is called. Each function call get their own execution context, completely separate from other contexts.
Eval Execution Context: Created when code is executed inside the eval() function. (Generally rare and not recommended for security/performance reasons).
We are going to ignore eval execution context in this article.

// This is how the JavaScript engine sees an Execution Context (conceptually)

ExecutionContext = {
    // Internal fields (you never see these directly):
    VariableEnvironment: { ... },    // Where local variables live
    LexicalEnvironment: { ... },     // For scope chain
    ThisBinding: ???,                // ← This stores the current 'this' value

    // Other internal metadata...
}

// When your code uses 'this', the engine looks up the ThisBinding field

Call Stack : Where and How are the Execution Contexts Stored ?

Everytime we call a function, a new execution context is created, but execution context is a data(metadata), creating and storing it consumes memory - RAM (Random Access Memory) to be specific. It is created when you run the code. The amount used by a single context memory is small (relatively), but it's very real. The contexts are organized in RAM through a list called Call Stack.
When the program runs, call stack organises the execution context in a LIFO (Last In First Out) fashion. Each function that are called have their metadata pushed to the top of the stack and are removed after the function executes.

let globalVar = "I'm global";

function outer() {
  let outerVar = "I'm outer";

  function inner() {
    let innerVar = "I'm inner";
    console.log(innerVar); // inner's Execution Context is on top of stack
  }

  inner(); // inner's context is created and pushed
  // inner's context is popped off the stack after it finishes
}

outer(); // outer's context is created and pushed
// outer's context is popped off the stack after it finishes

// Global Execution Context remains until the program ends.

Do Objects have an Execution Context of their Own?

Reading all this, you might wish to ask , or perhaps I should clarify : Do objects have a execution context of their own? Just like functions do?

The answer is No. Execution contexts track the Flow of Control, not the structure of data. Objects are data types that simply exist, they don't do anything.

Entity	Creates Execution Context?	Why?
Function	YES	Functions do something when called; calling them triggers a new context to manage their execution.
Object	NO	Objects are something (data storage); they exist in memory but do not execute code on their own.
Constructor	YES	A constructor is a specific type of function. Using `new` invokes it, which creates a new execution context to initialize the instance.
Prototype	NO	Prototypes are something (inheritance blueprints); they define shared behavior but are not executed directly.

// An object literal - NO execution context created
const car = {
    brand: "Toyota",
    year: 2024,
    start: function() {  // The function INSIDE will get a context when CALLED
        console.log(`${this.brand} starting`);
    }
};

// The object 'car' just sits in memory as data.
// No "execution" happens when you merely access it:
console.log(car.brand);  // Just data lookup, no new context

// But when you CALL the function:
car.start();  // YES! NEW execution context created for this function call

The `This` Keyword.

this is a special keyword in JavaScript, that points to the object that is currently the context of execution. This is an implicit parameter. That's all.

So what does that mean? As we already discussed, an object does not have an execution context, it does not do anything.
Here, the statement "Object that is currently the context of execution" means The object that the current function is acting or operating upon. Or it can be said as ' this refers to the object that is calling the function. '

const car = {
  brand: "Toyota",
  showBrand() {
    console.log(this.brand);
  }
};

car.showBrand(); // Output: "Toyota"
// 'this' refers to 'car' because 'car' called the function.

Context Object (semantic) --> "The object that the function is currently working on behalf of".

We know functions have their own context as metadata , now every executional context has a thisBinding property that lists the object that is calling the running function.

// The internal Execution Context (in the JavaScript engine) looks like this:       
// (You never see this directly)                                                   

ExecutionContext = {
    VariableEnvironment: { /* local variables */ },
    LexicalEnvironment: { /* scope chain */ },
    ThisBinding: window,  // ← 'this' is a PROPERTY of the execution context
    // ↑ 'this' does NOT point TO the context, 
    //   'this' is a VALUE INSIDE the context
}

// In your code:
console.log(this);  // This gives you the ThisBinding value

Anoter example,

// Think of it this way:

const executionContext = {           // Internal (you can't access this)
    variableEnv: { x: 5 },
    scopeChain: [...],
    thisBinding: myObject            // ← 'this' is just a property
};

// When you write 'this' in your code:
this    // You get executionContext.thisBinding

So, Why is this stored as thisBinding in Execution Context Metadata?
Because this can to be different for each function call, even when calling the same function.

const obj1 = { name: "A", greet() { console.log(this.name); } };
const obj2 = { name: "B", greet: obj1.greet };

obj1.greet(); // "A" (this = obj1)
obj2.greet(); // "B" (this = obj2) — same function, different this!

this is determined at call time, not definition time.

Why is `this` important ?

Importance 1: Method Reusability

// Without 'this', you'd need separate functions for each object
const alice = { name: "Alice", greet: function() { return "Hi from Alice"; } };
const bob = { name: "Bob", greet: function() { return "Hi from Bob"; } };
// Duplicate code everywhere!

// With 'this', one function works for ALL objects
function reusableGreet() {
    return `Hi from ${this.name}`;
}

alice.greet = reusableGreet;
bob.greet = reusableGreet;
// One function, infinite objects!

Importance 2: Object-Oriented Programming


// Without 'this', constructors couldn't work
function Person(name, age) {
    // 'this' allows us to refer to "the object being created"
    this.name = name;
    this.age = age;
    this.birthday = function() {
        this.age++;  // Updates the specific instance
    };
}

const alice = new Person("Alice", 30);
const bob = new Person("Bob", 25);

alice.birthday();  // Only alice's age increases to 31
console.log(alice.age);  // 31
console.log(bob.age);    // 25 (unchanged)

Importance 3: Dynamic Context

// 'this' allows functions to work with different objects dynamically
function updateProperty(value) {
    this.property = value;
}

const obj1 = {};
const obj2 = {};
const obj3 = {};

// Same function, three different targets
updateProperty.call(obj1, "first");
updateProperty.call(obj2, "second");
updateProperty.call(obj3, "third");

console.log(obj1.property);  // "first"
console.log(obj2.property);  // "second"
console.log(obj3.property);  // "third"

Importance 4: Event Handling (Browser)

// 'this' lets event handlers know WHICH element was clicked
document.querySelectorAll('button').forEach(button => {
    button.addEventListener('click', function() {
        // 'this' is the specific button that was clicked
        this.style.backgroundColor = 'red';
        this.disabled = true;
        console.log(`${this.id} was clicked`);
    });
});
// Without 'this', you'd need to pass the element manually every time

Important:

The arrow function is an exception to the rule of this referring to the calling object.
Arrow functions, inherit this from the surrounding (parent) execution context — at definition time, not call time.

  const obj = {
  name: "My Object",
  regularFunc: function() {
    console.log(this.name);  // `this` = obj (because of dot rule)
  },
  arrowFunc: () => {
    console.log(this.name);  // `this` = whatever it was OUTSIDE obj
  }
};

obj.regularFunc(); // "My Object" ✅
obj.arrowFunc();   // undefined (or global name) — not "My Object"

Trivia :

List => global vs window Available APIs:

// BROWSER window contains:
window.alert()      // Show popup
window.document     // DOM API
window.localStorage // Client storage
window.fetch()      // Network requests
window.requestAnimationFrame()
window.history
window.location

// NODE.JS global contains:
global.require()    // Module loading
global.module       // Current module
global.exports      // Module exports
global.process      // Process info
global.Buffer       // Binary data
global.setImmediate()
global.__dirname    // Current directory path
global.__filename   // Current file path

Objects exist in heap memory, don't confuse Heap with Call Stack:

Memory Area	Stores	Execution Context?
Call Stack	Execution contexts (function calls), variables, primitives	YES - Grows/shrinks as functions run
Heap	Objects, arrays, prototypes, closures	NO - Persistent data storage
Call Stack	Fast, fixed-size, LIFO (Last-In, First-Out)	Small, organized
Heap	Slower, flexible, no fixed order	Large, unstructured

Here's another nice table/graph:


/*
┌─────────────────────────────────────────────┐
│         Execution Context (internal)        │
├─────────────────────────────────────────────┤
│ • VariableEnvironment                       │
│   - local variables                         │
│   - function declarations                   │
│                                             │
│ • LexicalEnvironment                        │
│   - scope chain references                  │
│                                             │
│ • ThisBinding ───────┐                      │
└──────────────────────│──────────────────────┘
                       │
                       │ (points to)
                       ↓
              ┌─────────────────┐
              │  The value of   │
              │    'this'       │
              │  in your code   │
              └─────────────────┘
*/

// In your code:
this  // Accesses the ThisBinding from the current execution context

If you take a this.xyz here are some things it can refer to:

// 1. A regular object (most common)
const person = { name: "Alice", age: 30 };
person.describe = function() {
    console.log(this.name);     // 'this' = person object
    this.age++;                 // Modifies person.age
};
person.describe();  // 'this' points to person

// 2. The global object (window/global)
function showGlobal() {
    console.log(this.xyz);  // If xyz exists on global
}
showGlobal();  // 'this' = global object (window in browser)

// 3. undefined (in strict mode)
function showStrict() {
    "use strict";
    console.log(this);  // undefined
    // this.xyz would throw TypeError!
}
showStrict();

// 4. A primitive value (string, number, boolean)
function showPrimitive() {
    console.log(this);  // Could be "hello", 42, or true
    console.log(this.length);  // If string, logs its length
}
showPrimitive.call("hello");  // 'this' = "hello" (auto-boxed to String object)

// 5. null or undefined (intentionally)
function showNull() {
    console.log(this);  // null
}
showNull.call(null);  // 'this' = null

// 6. A new empty object (with constructor)
function Person(name) {
    this.name = name;   // 'this' = brand new empty object
    this.xyz = "custom"; // Adds property to new object
}
const alice = new Person("Alice");  // 'this' points to new object

// 7. Whatever you explicitly bind (using bind, call, apply)
const boundFunction = showGlobal.bind({ xyz: "custom value" });
boundFunction();  // 'this' = { xyz: "custom value" }

A complete picture:

/*
1. OBJECTS exist in heap memory
   - They just hold data (properties)
   - They don't "do" anything
   - They have NO execution context

2. FUNCTIONS also exist in heap memory
   - They contain code
   - They are inert until called

3. EXECUTION CONTEXTS exist temporarily on call stack
   - Created when functions are CALLED
   - Contain metadata for that specific call
   - Include thisBinding field

4. thisBinding stores a REFERENCE to an object
   - Connects the function call to data
   - Allows the function to work with different objects
   - The referenced object remains just an object (no context)
*/

Credits to: AI assistant - DeepSeek.

If you actually read this far Thank You Very Much! This is my second article written, leave a comment if you enjoyed it or found anything problematic.

Use Portable Git without Administrator Privileges on Windows OS

Priyanshu Jha — Sun, 31 May 2026 12:18:46 +0000

Introduction to Portable Git (Thumbdrive install)

You can use Git-- the version control system as a portable software on Windows , the portable git can acts same as normal git but without needing administrator privileges for installation, moreover you can carry it around on a USB flash drive with you, and use it with different computers.

This article explains what Portable Git is and why it’s useful, and walks through downloading, extracting, and using it. You’ll learn how to launch Git from a thumb drive, verify it’s working, and even adjust your system PATH so your PC recognizes it. In the end you will be shown some methods so that you don't have to manually set its PATH each time you use your thumbdrive. (We assume a 64-bit x64 Windows PC – if you have an ARM64 Windows device, use the ARM64 Portable Git version.).

We assume you have :

A 64-bit (x86_64/AMD64) or 64-bit ARM (ARM64) Windows computer running Windows 10/11.
Intermediate Windows knowledge: navigating folders, using Command Prompt, and setting environment variables.
A USB flash drive (or other portable storage) with enough space (about 60 MB free) for Git.
(Optional) Administrator access on your PC is not needed to run Portable Git, which is one of its main advantages.

⚠️ Important: Do not store or run a portable Git environment on a cheap, low-quality USB flash drive. Git performs frequent, small read/write operations that will quickly degrade cheap flash memory, leading to corrupted repositories and severe performance lag.

Minimum USB Drive Standards for Git

If you must run Git from a USB drive, ensure it meets these bare minimum specifications:

Interface: USB 3.0 or higher.
Memory Type: Solid State Flash (NAND) or "SSD-grade" flash controllers.
Speed Profile: Minimum 100 MB/s sequential write speed.
Random I/O: High 4K random read/write performance.
Build Quality: Metal housing for heat dissipation during heavy indexing.

What is portable Git ?

Portable Software is an application that runs without any installation into the main memory or C Drive where the program files are stored , instead it stores all its files inside its own folder, which we can carry in a storage device of our choice.

Git for Windows offers a thumbdrive edition specifically for this use case. Portable Git is simply the standard Windows Git client packaged so it can run from a USB drive. Because it does not modify the Windows registry or require an installer; it leaves no traces on the host computer and runs in isolation.

Why use it ?

Many Organisations block Administrator access becuause of Software Control, Licensing, Maintenance , Data Protection, Legal Safety Compliance concerns. Portable Git allows you to safely get around that.

Using Portable Git is handy in many scenarios: for example, if you want to use Git on a school, work, or shared computer where you can’t install software. You just plug in your flash drive, run Git, and work in any directory (even on the PC’s local drives) as if Git were installed. This keeps your Git environment and history in one place that you control.

Pros:

No installation or admin rights needed
Portable across machines.
No changes to system registry.
Consistent environment on any PC.
Easy to carry your repositories.

Cons:

You must manage updates manually.
Portable git can be slightly slower on a USB drive.
If the PC has a different default Git installed, you may need to adjust PATH; you will not get automatic shell integration (e.g. Git Bash) unless you launch it from the USB.

Do you need portable git?

If a computer already has a properly configured Git installation, most users may not need Portable Git at all.

A standard installation is usually simpler for everyday development.

Portable Git is most useful when:

There is no Git and administrator installation is restricted
Users need isolated/temporary Git environments
You want Latest or your preffered Git version
System modifications needs be avoided
Git must be carried between multiple computers

In other words, Portable Git is mainly about flexibility and portability rather than replacing a normal Git installation in all situations.

Downloading Portable Git

On a Windows PC, open your web browser and go to the Git for Windows download page.
Choose the “Portable (“thumbdrive edition”) link for your architecture (either “x64 Portable” or “ARM64 Portable”)【25†L46-L54】. This will download a self-extracting archive file (around 56–57 MiB for version 2.54, roughly 60 MB) to your Downloads folder. (For example, the file might be named PortableGit-2.54.0-64-bit.7z.exe for x64.)
Confirm the download finished. You should see something like PortableGit-*-bit.7z.exe in your Downloads folder.

At this point, you have a single .7z.exe file which is the portable Git package. It’s not installed yet; next we extract it.

Extracting Portable Git

Double-click the downloaded PortableGit-*.7z.exe file. A file extraction wizard should open (this is a 7-Zip self-extractor).

When prompted for a destination, the default location is C:\Users\priyanshu\Downloads\PortableGit since this is a "portable" Git we are dealing with, we do NOT install it in program files of the main memory (the default location you see as listed), it requires administrator permissions and other ramifications, instead choose a folder on your USB drive or other storage of your own choice.

Enter your preferred location , click Extract or Unzip. The program will unpack Git’s files into your chosen folder.

For our purposes we will extract it into an E drive (NVME SSD) as a portablity example and proof to show you first.

You can check if Git exists in your computer PATH or what version of Git it has with Git --version and where is it stored in your PATH as via where git command.
More on PATH later.

Note : It's possible that the first time your extraction may fail, don't worry and go ahead and try again, sometimes the extraction fails because you may not have created the PortableGit folder , e.g. in E:\Test-Folder\PortableGit the folder PortableGit may not be created.

Portability Test

Now let's perform a portability test.

We will cut and paste the Portable Git folder into a removable USB flash drive, and then test whether Git still works correctly from the new location.

This helps verify that Portable Git can run independently without requiring installation or administrator access.

After moving the folder to the USB drive, open Command Prompt inside the Portable Git directory and run:

Running Portable Git and Checking It Works

At F:\PortableGit the portable Git is moved to and available, now we do a test run by running Git Command Prompt from the folder without seeking any permissions.

👉 Double click git-cmd.exe , a command line interface should appear.

In this Git CMD window, type:

  git --version

You should see output like git version 2.54.0.windows.1 (version number may vary). This confirms Git is working.

Next, type:

  where git

This shows the path(s) where your Git is executing from. In the Git CMD shell, it will usually point to your USB path (e.g. F:\PortableGit\cmd\git.exe), indicating you’re using the portable Git.

What is PATH, Git-CMD , Git-Bash ?

### PATH
PATH is an environment variable in operating systems (Linux, macOS, Windows) that tells your system where to look for executable programs when you type a command.
Simply put, they are a bundle of directories to find and recognise commands in a command line interface.
Since portable git resides in a removable USB drive, it is not added to PATH.

### Git-CMD
Git-CMD.exe Is a file you find in a portable git folder right alongside Git-Bash.exe, double clicking this file opens a command prompt which is simply a windows command prompt but with PATH configured for your portable git.
### Git-Bash
Git Bash is a Unix/Linux style terminal that runs on Windows.

It supports:

Linux Commands on Windows
Git Commands (pre-configured) [Just like Git-CMD]
Shell Scripting
Pipes and Redirection

Use this if you are more familiar with Linux OS, Shell, or prefer the power of Linux

Git Bash vs Windows CMD vs Git CMD

Feature	Windows CMD	Git CMD	Git Bash
Git commands	✗	✓	✓
Windows commands (dir, copy)	✓	✓	Partially
Linux commands (ls, cat, grep)	✗	✗	✓
Shell scripting	✗	✗	✓
Pipes and redirection	Limited	Limited	✓ Full
Access all drives	✓	✓	✓
Powered by	Windows	Windows	MINGW (Linux tools)

Setting Git to PATH

Do you need it ?

Depends on :
Do you find it convenient to have use your portable git from anywhere on working device - PowerShell, Command Prompt, VS Code terminal ? Then yes !

But if you are fine with opening Git CMD or Bash by using your mouse and everytime you want to open a new window ? Then not really.

Manually adding Git to PATH

When you move your USB to another Windows PC, you can repeat the steps above by launching git-cmd.exe. But by default, Windows won’t recognize git on the command line unless you add it to the PATH. Here’s how to test and fix that:

On the new PC, plug in your USB and open File Explorer. Note the drive letter assigned (e.g. F:).
Open a standard Windows Command Prompt (not Git CMD). In it, type:

   git --version
   where git

If Git is not already installed on the PC, you’ll get an error or no result. If Git is installed system-wide, where git might show something like C:\Program Files\Git\cmd\git.exe. Either way, the portable Git isn’t yet in the PATH.

Temporarily add the USB Git to the PATH by running (replace F: with your actual drive letter):

   set PATH=F:\PortableGit\cmd;%PATH%

Make sure there are no spaces around the =. This prepends your USB’s Git folder to the PATH for this Command Prompt session.

Now type again:

   where git

You should see two entries: F:\PortableGit\cmd\git.exe above any C:\Program Files\Git\cmd\git.exe. The fact that the F: path comes first means your portable Git will be used in this session.

Tip: Keep your portable Git folder organized. If you want to use it on multiple drives, note the drive letter might change (E:, F:, etc.), so always check and adjust the path accordingly.

Test Git on this CMD prompt:

   git --version
   git init
   mkdir usb-test
   cd usb-test
   echo This is an example text > example.txt
   git add example.txt
   git status

You should again see Git initialized successfully and the new file listed by git status. All commands are being run by the portable Git from your USB.

Remember, the set PATH=... command only lasts for that Command Prompt window. If you open a new Command Prompt, you would need to repeat the set PATH step (or use setx to make it permanent, which requires admin rights). For occasional use, it’s fine to just do it manually each time.

Tip: If you ever need to “uninstall” portable Git from a PC, simply delete the extracted Git folder or remove it from the PATH (since it didn’t install, there’s no uninstaller)

You should now be able to use Git as a Portable Software.

DEV Community: Priyanshu Jha

[Boost]

Execution Context and Object Context - Clarifying `window` , `global` and `this` in JavaScript.

Execution Context and Object Context - Clarifying `window` , `global` and `this` in JavaScript.

Introduction - This article is for clarity

What is an Execution Context?

Call Stack : Where and How are the Execution Contexts Stored ?

Do Objects have an Execution Context of their Own?

The This Keyword.

Why is this important ?

Important:

Trivia :

Use Portable Git without Administrator Privileges on Windows OS

Introduction to Portable Git (Thumbdrive install)

We assume you have :

Minimum USB Drive Standards for Git

What is portable Git ?

Why use it ?

Do you need portable git?

Downloading Portable Git

Extracting Portable Git

Portability Test

Running Portable Git and Checking It Works

What is PATH, Git-CMD , Git-Bash ?

Git Bash vs Windows CMD vs Git CMD

Setting Git to PATH

Do you need it ?

Manually adding Git to PATH

The `This` Keyword.

Why is `this` important ?