Forem: Dineshraj Anandan

🚀 Stop Burning Money on AI Tools - Use Cursor Like a Pro

Dineshraj Anandan — Wed, 18 Mar 2026 16:26:53 +0000

You wouldn't leave your car engine running while you grab groceries. So why are you burning thousands of tokens on a chat that's asking an AI to "look at your entire repo"?

AI coding tools like Cursor, Claude Code, and GitHub Copilot are genuinely life-changing for developers. But here's the uncomfortable truth nobody tells you when you sign up:

Most developers use them inefficiently, and pay for it.

This guide is your no-nonsense, zero-fluff walkthrough to using AI coding tools smarter. Whether you're a solo dev, an engineering lead watching the cloud bill creep up, or just someone who's tired of slow, confused AI responses. This one's for you.

🧠 First, Understand What You're Actually Paying For

LLMs charge by tokens. Think of a token as roughly a word, or sometimes just a syllable.

Every time you hit send, you're paying for:

Type	What's Included
Input tokens	Your prompt + chat history + attached files + context
Output tokens	Code generated + explanations + suggestions

Total Cost = Input Tokens + Output Tokens

Sounds simple. Here's where it gets sneaky.

🔁 The Dirty Secret: LLMs Have No Memory

LLMs are stateless. They remember nothing.

So every single message you send? The tool secretly resends your entire conversation from the beginning. Every. Single. Time.

You → "Fix this function"         ← 200 tokens
You → "Make it async"             ← 400 tokens (history resent)
You → "Add error handling"        ← 800 tokens (history resent again)
...
You → Message #10                 ← Several thousand tokens 💸

This is called token compounding, and it's silently draining your usage quota. A casual 20-message debug session can cost 10x more than it should.

💀 What Happens When Context Gets Too Full?

In Cursor, you'll see a little indicator:

38.2% context used

Think of this as a whiteboard. The AI can only see what's on the board. When it fills up:

🧠 Important details get erased
🐌 Responses get slower
🤷 Accuracy tanks and the AI starts guessing

Here's a simple rule of thumb:

Context Level	What to Do
< 40%	You're golden ✅
40–70%	Keep an eye on it 👀
70–90%	Start a new chat soon
> 90%	You're basically yelling into the void

💡 The Fix: Treat AI Chats Like Sticky Notes, Not Journals

Here's the mental model shift that changes everything:

Treat each chat like a temporary sticky note. Not a long-running conversation.

Write what you need, get the answer, move on.

❌ The Way Most People Work

One giant chat → entire day of development

Debugging a login bug → then asking about SQL → then generating a React component → then refactoring a service layer → all in the same chat.

That's not a conversation. That's a novelette. And you're paying per word.

✅ The Right Way

Chat 1 → Fix login API bug         (done, close it)
Chat 2 → Optimize SQL query        (done, close it)
Chat 3 → Generate React component  (done, close it)
Chat 4 → Refactor caching layer    (done, close it)

Smaller context = faster responses + lower cost + more accurate outputs. It's a triple win.

🗜️ When a Chat Gets Long But Useful, Summarize It

Sometimes you've been deep in a debugging rabbit hole and the context is gold but getting huge. Don't just abandon it.

Ask the AI to summarize before you start fresh:

Summarize this conversation in bullet points so I can paste it into a new chat.

You'll get something like:

- Project: .NET Web API
- Problem: Cosmos DB queries hitting cache too frequently
- Goal: Reduce redundant reads with smarter TTL
- Relevant files: CacheService.cs, CosmosRepository.cs

Then:

Open a new chat
Paste the summary
Continue exactly where you left off with a fraction of the token cost

In Claude Code, you can also use /compact to auto-summarize. In Cursor, just ask manually.

🎯 Use the Right Model for the Job

This one feels obvious, but almost nobody does it consistently.

Not every task needs the most powerful (and most expensive) model in the lineup.

Use Powerful Model For 🔥	Use Lighter Model For ⚡
Complex algorithms & logic	Simple implementations
Deep debugging & root-cause fixes	Coding from a clear plan
System design & architecture	Writing documentation
Performance optimization	Syntax fixes & formatting
Large refactors / code rewrites	Small edits & boilerplate
Ambiguous / open-ended problems	Repetitive or well-defined tasks

Here's a rough sense of the cost difference at scale:

Model	Input (per 1M tokens)	Output (per 1M tokens)
Claude Opus	~$5	~$25
Claude Sonnet	~$3	~$15
Gemini Flash	~$0.5	~$3

Ref: https://cursor.com/docs/models-and-pricing#model-pricing

Using Opus to rename a variable is like hiring a principal engineer to fix a typo. Use Sonnet. Save Opus for the hard stuff.

In Claude Code, switch models with:

/mod sonnet

📎 Attach Only What's Relevant

This one stings because it feels helpful to give the AI everything.

@entire-project   ← please don't

Every file you attach is more input tokens. More cost. More noise for the AI to wade through.

Instead:

@AuthController.cs
@TokenService.cs

Give it the files it actually needs. Your wallet (and your response quality) will thank you.

✂️ Break Big Tasks Into Small Steps

Instead of:

Build the entire authentication system with JWT, refresh tokens, 
middleware, and role-based access control.

Try:

Step 1 → Create the login API endpoint
Step 2 → Add JWT token generation
Step 3 → Implement refresh token logic
Step 4 → Add role-based middleware

Each step = a focused, cheap, accurate response. All in one go = an expensive, possibly hallucinated mess.

📊 Monitor Your Usage Dashboard

Cursor has a billing dashboard at:

https://cursor.com/dashboard → Usage

Check it regularly. You'll see two buckets:

Included Usage - What your plan covers:

Plan	Included
Pro	~$20
Pro+	~$70
Ultra	~$400

On-Demand Usage - What you pay extra when you go over. Sneaks up fast if you're not watching.

Set a reminder to check it. It takes 30 seconds and can save you from a surprise bill.

✅ Your Pre-Prompt Checklist

Before you hit send on your next prompt, run through this:

Is this a new task? → Open a new chat
Is context above 70%? → Summarize and restart
Am I attaching only relevant files? → Remove the rest
Is the right model selected for this task?
Is my prompt specific and focused?
Have I broken this into smaller steps if it's complex?

🧵 The TL;DR (For the Skimmers)

Start a new chat per task, token compounding is real and it's expensive
Summarize long chats before switching topics, not after
Use Sonnet for everyday tasks, Opus only when you really need it
Attach fewer files , precision beats coverage
Break big prompts into steps, better results, lower cost
Check your dashboard regularly, no one likes surprise bills

The core principle: AI chats are temporary working memory ,not a permanent journal. Keep them short, focused, and task-specific. You'll get better answers, faster responses, and a much friendlier bill at the end of the month.

Found this useful? Share it with your team, especially that one colleague who's been running a 200-message conversation for three days straight. 👀

The Life and Death of Variables: Memory Management in JS

Dineshraj Anandan — Mon, 03 Nov 2025 11:07:39 +0000

Ever wondered what happens to all those objects you create in JavaScript? Unlike low-level languages like C, where developers manually allocate and free memory using malloc() and free(), JavaScript handles memory management automatically. But how does it work under the hood? Let's explore the fascinating world of garbage collection.

The Automatic Memory Janitor

JavaScript's garbage collector is like an invisible janitor working in the background, constantly monitoring your application's memory and cleaning up what's no longer needed. The engine automatically tracks objects through multiple phases, checking if they're still referenced by your program and releasing their memory when they're not.

But here's the catch: determining whether memory "is not needed anymore" is fundamentally an undecidable problem in computer science. So how do JavaScript engines tackle this challenge?

The Core Concept: Reachability

Modern garbage collection relies on one elegant principle: reachability. In the context of memory management, an object is considered reachable if your code can access it, either directly or through a chain of references.

Think of it like this: if you can't get to an object by following a path from your code's "roots" (like global variables or the current call stack), then it's effectively dead weight that can be cleaned up.

Mark-and-Sweep: The Foundation

All modern JavaScript engines use a variation of the Mark-and-Sweep algorithm. This clever approach reduces the complex question of "Is this object needed?" to the simpler "Is this object reachable?"

Here's how it works in two distinct phases:

Phase 1: Marking

The garbage collector starts from root objects (global variables, objects on the call stack) and traverses the entire object graph, marking every reachable object as "in-use." It's like tracing a web of connections, following every link from the roots.

Phase 2: Sweeping

After marking, the collector scans the memory heap and reclaims memory from all unmarked objects. If it wasn't marked, it's unreachable and therefore safe to collect.

While this algorithm has remained fundamentally unchanged, modern improvements in the field (generational, incremental, concurrent, and parallel garbage collection) have focused on optimizing how it's implemented, not the core algorithm itself.

Generational Garbage Collection: Working Smarter

Here's an interesting observation: most objects in JavaScript are short-lived. They're created, used briefly, and then abandoned. JavaScript engines leverage this pattern through generational garbage collection, dividing the memory heap into generations based on object lifespan.

Young Generation (The Nursery)

Newly created objects start here. Since most objects die young, this area is collected frequently using a fast process called scavenging. Think of it as a quick sweep that happens often, efficiently reclaiming memory from short-lived objects without scanning the entire heap.

Scavenging is a highly efficient, stop-the-world algorithm that quickly identifies live objects and copies them from one memory space to another, leaving dead objects behind to be reclaimed.

Old Generation (The Tenured Space)

Objects that survive multiple garbage collection cycles in the young generation get "promoted" to the old generation. These long-lived objects are collected less frequently using full Mark-and-Sweep, which is more computationally intensive but happens much less often.

This two-tier approach dramatically improves performance by focusing resources where they're most needed.

The Limitation: No Manual Control

Unlike lower-level languages, JavaScript doesn't allow manual garbage collection control and this is by design. You cannot programmatically trigger garbage collection in core JavaScript (nor will you likely ever be able to). To release an object's memory, you must make it explicitly unreachable by removing all references to it.

However, there are ways to peek under the hood...

Tracing Garbage Collection in Node.js

Want to see garbage collection in action? Node.js provides flags that let you trace GC events:

Let's create a test script that deliberately stresses the garbage collector to observe both types of GC in action:

const leaks = [];

function generateGarbage() {
  const largeArray = [];
  for (let i = 0; i < 100; i++) {
    largeArray.push(new Array(100).join('.'));
  }
}

function retainMemory() {
  const persistentArray = new Array(100);
  for (let i = 0; i < 100; i++) {
    persistentArray[i] = new Array(100).join('.');
  }
  leaks.push(persistentArray);
  if (leaks.length > 5) {
    leaks.shift(); // Release old memory for collection
  }
}

// Continuously allocate and retain memory
let counter = 0;
const interval = setInterval(() => {
  generateGarbage();
  retainMemory();
  console.log('Heap status:', process.memoryUsage());
  if(counter > 100){
    clearInterval(interval);
  }
  counter++;
}, 100);

What This Code Does

This script is specifically designed to trigger different types of garbage collection:

generateGarbage() creates short-lived objects that immediately become unreachable after the function returns. These objects are perfect candidates for young generation collection (scavenging). Since largeArray is a local variable with no external references, it becomes garbage as soon as the function exits.

retainMemory() creates long-lived objects by storing them in the global leaks array. These objects remain reachable and will survive multiple GC cycles, eventually getting promoted to the old generation. The function maintains a rolling window of 5 arrays, so older ones are eventually released by calling leaks.shift(), making them eligible for collection.

The interval loop runs every 100ms, continuously creating both types of memory pressure. This rapid allocation forces frequent garbage collection cycles, making GC activity visible in the trace output. Running it 100+ times ensures you'll see both minor (scavenge) and major (mark-sweep) collections.

⚠️ Warning: Execute the code with caution

Why This Script Is Perfect for Tracing

This code is ideal for observing GC behavior because it:

Creates predictable memory patterns - You can clearly see the difference between short-lived garbage and retained objects
Generates enough memory pressure - Rapid allocation triggers frequent GC events that show up in traces
Demonstrates generational behavior - Objects that survive (leaks array) will be promoted to old generation, while temporary objects are quickly scavenged
Shows the full lifecycle - Both allocation and deallocation (via shift()) are visible

Run this with tracing enabled:

node --trace-gc your-script.js

This outputs GC events showing:

Type of GC (Scavenge for young generation, Mark-sweep for old generation)
Memory before and after collection (showing how much was reclaimed)
Time spent in GC (revealing performance impact)

You will see output like:

[16215:0x150008000]     8795 ms: Scavenge 5.6 (8.3) -> 4.1 (8.3) MB, 0.17 / 0.00 ms  (average mu = 1.000, current mu = 1.000) task; 
[16215:0x150008000]     9023 ms: Mark-Compact (reduce) 4.9 (8.3) -> 3.0 (5.3) MB, 1.46 / 0.00 ms  (+ 1.3 ms in 7 steps since start of marking, biggest step 0.3 ms, walltime since start of marking 3 ms) (average mu = 1.000, current mu = 1.000) finalize incremental marking via task; GC in old space requested

For more details, use:

node --trace-gc --trace-gc-verbose your-script.js

Manual Triggering (Not Recommended for Production)

You can manually trigger GC using the --expose-gc flag, but this is strictly for debugging purposes:

node --expose-gc your-script.js

if (global.gc) {
  global.gc(); // Manually trigger garbage collection
}

Important: Never use this in production environments. The garbage collector is optimized to run at the right times. Manual intervention usually does more harm than good.

Tracing GC and triggering GC can also be done on frontend apps using Browser DevTools

The Bottom Line

JavaScript's garbage collection is a sophisticated system that operates silently, allowing developers to focus on building features rather than managing memory. While you can't control it directly, understanding how it works helps you write more memory-efficient code and debug potential memory leaks.

The key takeaway? Make objects unreachable when you're done with them, and let the garbage collector do its job. It's been optimized for decades. Trust the process.

Understanding SSL/TLS Certificates: Your Website's Digital Passport

Dineshraj Anandan — Thu, 11 Sep 2025 16:03:33 +0000

Every time you shop online, log into your bank account, or enter personal information on a website, you're trusting that your data remains private and secure. The technology that makes this possible? SSL/TLS certificates. These digital guardians work behind the scenes to encrypt your information and verify that you're actually communicating with the legitimate website you intended to visit.

Understanding SSL vs TLS: The Evolution of Web Security

SSL (Secure Sockets Layer) was the original protocol designed to secure internet communications. However, SSL has been deprecated due to security vulnerabilities and is no longer considered safe for modern use.

TLS (Transport Layer Security) is the modern, more secure successor to SSL. Despite this evolution, the term "SSL certificate" remains widely used in the industry even when referring to TLS certificates. Think of it like how we still say "dialing" a phone number, even though phones haven't had dials for decades.

Today's websites use TLS 1.2 or TLS 1.3, which provide robust encryption and security features that keep your data safe from cybercriminals.

The Problem with Plain HTTP

When you visit a website using HTTP (HyperText Transfer Protocol), your communication with the server is completely unencrypted. This means:

Data travels in plain text: Anyone monitoring network traffic can read your passwords, credit card numbers, and personal information
No identity verification: You can't be certain you're actually communicating with the legitimate website
Vulnerable to tampering: Attackers can modify the data being sent between you and the server

Imagine sending a postcard through the mail with your banking password written on it. That's essentially what HTTP does with your sensitive information.

How HTTPS Solves These Problems

HTTPS = HTTP + TLS

When you see "https://" and a padlock icon in your browser's address bar, it means:

✅ Your data is encrypted during transmission
✅ The website's identity has been verified by a trusted authority
✅ Data integrity is protected against tampering

How SSL/TLS Certificates Work: The Technical Process

The TLS Handshake Process

When you visit a secure website, a complex but lightning-fast process occurs:

Initial Contact: Your browser connects to the server and requests a secure connection
Certificate Presentation: The server sends its SSL/TLS certificate to your browser
Certificate Verification: Your browser checks if the certificate is valid, not expired, and issued by a trusted Certificate Authority
Key Exchange: Both parties generate and exchange cryptographic keys
Secure Communication Begins: All subsequent data is encrypted using these keys

This entire process typically takes just milliseconds but creates an incredibly secure communication channel.

The Role of Certificate Authorities (CAs)

Certificate Authorities are organizations that act like digital notaries. They:

Verify the identity of websites and organizations
Issue SSL/TLS certificates after validation
Maintain the trust infrastructure that browsers rely on
Monitor for fraudulent certificate requests

Major CAs include DigiCert, Let's Encrypt, GlobalSign, and Sectigo. Your browser and operating system maintain lists of trusted root CAs, which forms the foundation of web security.

Recognizing Secure Websites: Browser Indicators

Positive Security Indicators

Padlock icon 🔒 in the address bar
"https://" prefix in the URL
"Secure" or "Connection is secure" text when clicking the padlock

Warning Signs

"Not Secure" warning for HTTP sites
Red warning screens for invalid or expired certificates
Mixed content warnings when secure pages load insecure resources

Inspecting Certificate Details

Click the padlock icon to view:

Issued to: The domain name(s) covered by the certificate
Issued by: The Certificate Authority that validated and issued the certificate
Valid from/to: The certificate's validity period
Encryption details: The cryptographic algorithms and key lengths used

Types of SSL/TLS Certificates by Validation Level

Domain Validated (DV) Certificates

Validation Process: Automated verification that you control the domain
Validation Time: Minutes to hours
Use Cases: Personal blogs, small business websites, informational sites

How to Identify: The certificate shows the domain name but no organization information. Most common and cost-effective option.

Organization Validated (OV) Certificates

Validation Process: Domain control + business verification through official records
Validation Time: 2-5 business days
Use Cases: Business websites, e-commerce sites, professional services

How to Identify: Certificate details include verified organization name and location information.

Extended Validation (EV) Certificates

Validation Process: Comprehensive verification including legal, physical, and operational business existence
Validation Time: May take long
Use Cases: Banks, major e-commerce platforms, high-security applications

How to Identify: Organization name appears prominently in certificate details.

Types of SSL/TLS Certificates by Domain Coverage

Single Domain Certificates

Protects exactly one domain (e.g., example.com)
Does not cover subdomains like www.example.com or mail.example.com
Most basic and affordable option

Wildcard Certificates

Protects one domain and all its first-level subdomains
Example: *.example.com covers www.example.com, api.example.com, shop.example.com
Cost-effective for organizations with multiple subdomains

Multi-Domain (SAN) Certificates

Protects multiple completely different domains on one certificate
Example: Can cover example.com, mystore.net, and businessname.org
Useful for organizations managing multiple brand domains
Supports up to 100-250 domains depending on the CA

Key Components of SSL/TLS Certificates

Every SSL/TLS certificate contains essential information:

Public Key: Used for encryption and digital signature verification
Subject Information: Domain name(s) and organization details (if applicable)
Issuer Information: Certificate Authority details and digital signature
Serial Number: Unique identifier for the certificate
Validity Period: Start and expiration dates
Signature Algorithm: Cryptographic algorithm used (e.g., SHA256)
Key Usage Extensions: Defines what the certificate can be used for

Understanding the Certificate Chain of Trust

SSL/TLS security relies on a hierarchical trust system:

The Trust Hierarchy

Root CA Certificate: Self-signed certificate that browsers inherently trust
Intermediate CA Certificate(s): Signed by the Root CA, provides operational flexibility
End-Entity Certificate: Your website's certificate, signed by an Intermediate CA

Why Use Intermediate Certificates?

Security: Root CA private keys can be kept offline and highly secured
Scalability: Intermediate CAs can handle day-to-day certificate issuance
Flexibility: Multiple intermediate CAs can operate under one root

Verification Process

When you visit a website, your browser:

Receives the website's certificate
Follows the chain up to a trusted root CA
Verifies each signature in the chain
Ensures no certificates are expired or revoked
Confirms the certificate matches the domain you're visiting

How Browsers and Operating Systems Know Which Root CAs to Trust

The foundation of SSL/TLS security relies on a pre-established list of trusted Certificate Authorities that are built into your operating system and browser. These root certificates are maintained by different organizations:

Windows: Microsoft maintains the Windows Root Certificate Program
macOS/iOS: Apple manages its own root certificate store
Chrome: Uses the operating system's root store
Firefox: Maintains its own independent root store based on Mozilla's CA Certificate Program

Certificate Authorities must undergo rigorous evaluation to be included, including security audits, policy compliance, and ongoing monitoring. This process can take months or years, ensuring only trustworthy CAs are included.

Viewing Trusted Root Certificates on Different Platforms

Windows: Certificate Manager

Press Windows Key + R to open the Run dialog
Type certmgr.msc and press Enter
Navigate to Trusted Root Certification Authorities > Certificates
You'll see all trusted root certificates installed on your system

macOS: Keychain Access

Press Cmd + Space to open Spotlight search
Type "Keychain Access" and press Enter
Navigate to System > System Roots

Google Chrome: Certificate Settings

Type chrome://settings/certificates or chrome://certificate-manager in the address bar
Click the Chrome Root Store tab to view trusted root certificates

Best Practices and Recommendations

Choosing the Right Certificate

Personal/small business sites: Domain Validated (DV) certificate
Business websites: Organization Validated (OV) certificate
High-security applications: Extended Validation (EV) certificate
Multiple subdomains: Wildcard certificate
Multiple domains: Multi-domain (SAN) certificate

Security Best Practices

Use TLS 1.2 or higher (disable older versions)
Monitor certificate expiration dates and set up automatic renewal
Implement proper certificate chain configuration
Regular security audits of your TLS configuration

Conclusion

SSL/TLS certificates are fundamental to modern web security, protecting billions of online interactions every day. Understanding how they work, the different types available, and best practices for implementation helps ensure your websites and applications provide the security your users expect and deserve.

Whether you're a website owner securing your first site or a developer implementing enterprise-grade security, choosing the right SSL/TLS certificate and implementing it properly is one of the most important steps you can take to protect your users data and maintain their trust.

Node.js Event Loop Explained

Dineshraj Anandan — Sun, 17 Aug 2025 02:53:19 +0000

Node.js is single-threaded, meaning it executes JavaScript code in sequence on a single main thread. Yet, it’s famous for handling thousands of concurrent operations without slowing down. The secret behind this magic?

The Event Loop, the core mechanism that lets Node.js handle asynchronous operations (like network requests, file system reads, or timers) without blocking the main thread.

Why should I understand event loop?

The Event Loop is at the heart of Node.js’s asynchronous programming model.

Understanding how it works and how callbacks, promises, and async/await fit into it gives you the power to write faster, more predictable, and bug-free asynchronous code. Without this understanding, you risk introducing hard-to-debug race conditions, blocking the thread, or misusing async patterns.

Analogy: A One-Server Restaurant

Imagine a small restaurant with one server who handles multiple responsibilities:

Taking orders from customers
Informing the kitchen about orders
Delivering food when it's ready

Here's how it works:

Customer 1 arrives: Server gives them a menu and takes their pizza order.
Server informs kitchen: Kitchen acknowledges and starts preparation.
Customer 2 arrives: Instead of waiting for the pizza, server immediately takes their biryani order.
Kitchen works in parallel: Both orders are being prepared simultaneously.
Pizza ready: Server delivers it to Customer 1.
Biryani ready: Server delivers it to Customer 2.
This cycle repeats for every customer.

The server never waits idle. They efficiently manage multiple customers while food is prepared in the background. That’s exactly how Node.js stays responsive.

In Node.js terms:

Server = Event Loop (single-threaded)
Kitchen staff = libuv thread pool + OS kernel
Orders = Asynchronous tasks
Order notes = Event queues
The continuous process = The Event Loop cycle

The Event Loop

The event loop allows Node.js to be single-threaded while still handling many concurrent operations. Instead of waiting for a task (like a database query or file read) to finish, Node.js offloads it to the operating system and moves on to the next task. When the offloaded task is complete, a callback function is put into the event queue. The event loop constantly monitors this queue and, when the call stack is empty, it moves the callback from the queue to the stack to be executed.

Here's the step-by-step process:

Node.js starts: Executes your initial script synchronously
Encounters async operations: When it finds setTimeout, fs.readFile, etc., Node.js:
- Delegates the operation to libuv or the OS
- Registers the callback function
- Continues executing the next synchronous code
Operations complete: When async operations finish, their callbacks are placed in appropriate queues
Event loop activates: Once the call stack is empty, the event loop:
- Processes all microtasks first
- Then processes macrotasks phase by phase
- Repeats this cycle continuously

Key Rule: The event loop only processes queued callbacks when the call stack is completely empty.

Event Loop Phases

   ┌───────────────────────────┐
┌─>│           timers          │  <- setTimeout, setInterval callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │  <- TCP/UDP connection callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │  <- Internal Node.js operations
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │  <- Most I/O operations
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │  <- setImmediate callbacks
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │  <- Socket.on('close'), cleanup
   └───────────────────────────┘

1. Timers Phase

Executes callbacks scheduled by setTimeout() and setInterval()
Only runs callbacks whose timer has expired

2. Pending Callbacks Phase

Handles callbacks for completed TCP/UDP socket connections

3. Idle, Prepare Phase

Internal Node.js operations
Not directly relevant to application code

4. Poll Phase (Most Important)

Fetches new I/O events (like file reads, network requests, and database queries) and executes their callbacks
This is where most application code runs
If poll queue is empty:
- Checks for setImmediate() callbacks → moves to check phase
- Otherwise, waits for incoming callbacks

5. Check Phase

Executes setImmediate() callbacks
Runs immediately after poll phase if poll becomes idle

6. Close Callbacks Phase

Handles cleanup callbacks (e.g., socket.on('close'))
Ensures proper resource cleanup

Important: After each phase, all microtasks are processed before moving to the next phase.

Microtasks

The Node.js event loop has two main queues for asynchronous tasks:

Microtask Queue: This queue holds higher-priority tasks. process.nextTick() , queueMicrotask() and promises (.then(), .catch(), .finally()) are the primary examples of microtasks. The event loop empties the entire microtask queue after each phase of the event loop and before moving to the next one.
Macrotask Queue: This queue holds lower-priority tasks. Examples include setTimeout, setImmediate, and I/O callbacks. The event loop processes one macrotask per cycle.

Because of this priority system, if you have a process.nextTick and a setTimeout scheduled at the same time, the nextTick callback will always run first. This behavior makes nextTick useful for tasks that need to be "immediately" asynchronous.

Event loop executes tasks in process.nextTick queue first, and then executes promises microtask queue, and then executes macrotask queue.

Execution Order Example

const baz = () => console.log('baz');
const foo = () => console.log('foo');
const zoo = () => console.log('zoo');

const start = () => {
  console.log('start');                    // 1. Synchronous

  setImmediate(baz);                       // 5. Macrotask (check phase)

  new Promise((resolve, reject) => {
    resolve('bar');                        // 2. Promise resolves synchronously
  }).then(resolve => {
    console.log(resolve);                  // 3. Microtask (promise)
    process.nextTick(zoo);                 // 4. Microtask (nextTick)
  });

  process.nextTick(foo);                   // 2. Microtask (nextTick)
};

start();

// OUTPUT:
// start    ← Synchronous execution
// foo      ← process.nextTick (highest priority microtask)
// bar      ← Promise then callback
// zoo      ← process.nextTick (added during promise callback)
// baz      ← setImmediate (macrotask, runs after all microtasks)

Execution Timeline:

console.log('start') runs immediately (synchronous)
setImmediate(baz) is scheduled for check phase
Promise resolves and .then() callback is queued as microtask
process.nextTick(foo) is queued as microtask
Call stack becomes empty → Event loop starts
All microtasks run: foo, then promise callback (bar), then zoo
Move to check phase and run baz

Note: The principle aforementioned holds true in CommonJS cases, but keep in mind in ES Modules, e.g. mjs files, the execution order will be different. The ES Module being loaded is wrapped as an asynchronous operation, and thus the entire script is actually already in the promises microtask queue.

What is libuv?

libuv is a cross-platform C library that provides the core functionality for Node.js's asynchronous, non-blocking I/O operations. In simple terms, it's the "engine" that powers the Node.js event loop. It was primarily developed for use by Node.js.

libuv allows Node.js to perform I/O operations (like reading files, making network requests, and interacting with the file system) without blocking the main thread. It does this by offloading these tasks to the operating system or a thread pool, and then a callback is triggered once the operation is complete.

https://docs.libuv.org/en/v1.x/

Summary

The Node.js event loop is a sophisticated system that enables single-threaded JavaScript to handle thousands of concurrent operations efficiently. Key takeaways:

Single-threaded: JavaScript runs on one thread, but I/O operations are handled asynchronously
Event-driven: Callbacks are queued and processed when the call stack is empty
Phase-based: The event loop processes different types of callbacks in specific phases
Priority system: Microtasks always run before macrotasks
Non-blocking: Properly written async code never blocks the event loop
libuv-powered: The C library handles the heavy lifting of async operations

Understanding the event loop empowers you to write faster, more predictable Node.js applications. The key is to embrace asynchronous patterns and avoid blocking operations that could slow down your entire application.

Remember: The event loop constantly orchestrates the flow of tasks between the Call Stack, Event Queues, and Microtask Queue, powered by libuv's ability to handle I/O asynchronously. This ensures that a single-threaded process can efficiently manage multiple operations without getting blocked.

Web Development for Beginners: Build Projects, Learn Faster

Dineshraj Anandan — Sun, 17 Aug 2025 02:51:57 +0000

When it comes to learning Web UI development, I believe strongly in learning by doing.

Think about how we learned to walk as children. We didn’t watch tutorials. We tried, failed, crawled, and eventually walked and ran. Learning a new skill, especially something practical like frontend development, works the same way.

Video tutorials are helpful, but simply watching them won’t help you retain knowledge in the long run. You have to build things. Get your hands dirty. Learn by doing.

🌱 Where to Start: Hands-on Practice

One website I highly recommend for practicing frontend skills is:

👉 Frontend Mentor

Frontend Mentor offers real-world frontend challenges categorized by skill level:

Newbie
Junior
Intermediate
Advanced
Guru

Each challenge gives you a design to build responsively. After submission, you can:

Compare your solution with design expectations
Get improvement suggestions
Request constructive feedback from the community

💡 Tip: Start with Newbie challenges and work your way up gradually. You can start with the free plan and later upgrade to access Figma files, premium challenges, and unlimited screenshots if needed.

🧱 Learn the Fundamentals First

If you're completely new to HTML and CSS, take a short beginner-friendly course on YouTube to get started.

Don’t stat trapped in tutorial mode. Watch a bit. Then start building.

While Frontend Mentor allows using frameworks, I suggest solving the beginner-level challenges using vanilla HTML, CSS, and JavaScript. This will give you a strong foundation. You can always explore frameworks later as you advance.

🎯 Fun & Interactive CSS Learning Resources

Here are a few websites that help you practice CSS concepts through interactive games:

These are fun and effective ways to strengthen your layout and positioning skills.

⚙️ Start Building with JavaScript

Once you're comfortable with HTML and CSS, begin learning JavaScript. It’s essential for creating interactive UIs.

Start with a short course on YouTube or a learning platform of your choice. But don’t just watch. Build.

Here are some beginner project ideas:

To-do List App

Add, remove, and mark tasks as completed. Practice DOM manipulation, event listeners, and local storage.
Calculator App

Build a basic calculator. Understand user input handling, conditionals, and displaying results.
Digital Clock

Show the current time and update every second. Learn about the Date object and setInterval().
Rock, Paper, Scissors Game

Play against the computer. Use random logic, conditionals, and dynamic DOM updates.

🚀 After the Basics: Pick a Framework

Once you're confident with the basics, move on to a JavaScript framework or library. Some popular ones include:

Choose one that aligns with your goals or job aspirations. Then, start building projects with it.

🧠 Final Thoughts

No matter where you are on your journey, remember:

Build something.

You’ll learn more from one real-world project than from 10 hours of tutorials. Make mistakes, debug issues, and grow. That’s how real developers are made.

✍️ Thanks for reading! If you're just starting out or already on your frontend journey, I’d love to hear what you're working on or what helped you most. Let’s connect in the comments 👇