Open Forem: CodeWithIshwar

Understanding JavaScript Internals (What Most Developers Miss)

CodeWithIshwar — Wed, 29 Apr 2026 17:20:33 +0000

Most developers think they know JavaScript.

I thought the same.

Until I realized… I only knew the syntax—not what’s happening underneath.

⚡ Why JavaScript Feels Confusing

It’s not random.

It’s just misunderstood.

JavaScript is powerful because of how it behaves under the hood, not just its features.

🧠 Functions are First-Class

You can pass, return, and store functions anywhere.

That’s why:

callbacks
middleware
hooks

…are even possible.

🔁 Closures = Functions with Memory

A function doesn’t forget its scope.

Even after execution, it remembers where it came from.

This powers:

data privacy
encapsulation
patterns used in modern frameworks
⏳ Event Loop = Async Explained

JavaScript is single-threaded.

But still handles async smoothly.

Why?

Because of:

call stack
callback queue
microtask queue

👉 That’s why Promise runs before setTimeout

🧩 Prototypes (Real Inheritance)

Objects inherit from other objects.

Classes?

Just syntactic sugar.

⚡ Type Coercion (Helpful… Until It’s Not)
[] + {} // "[object Object]"

If you don’t understand coercion, bugs feel random.

🧠 Almost Everything is an Object

Functions, arrays, even primitives (via wrappers)

Once you see this, JavaScript starts feeling consistent.

💡 The Shift That Matters

Beginner:
“I know JavaScript syntax”

Advanced:
“I understand how JavaScript behaves”

🔥 Final Thought

JavaScript doesn’t get easier when you memorize more.

It gets easier when you understand the patterns underneath.

💬 What concept made JavaScript finally “click” for you?

🏷️ Tags

javascript #webdev #programming #frontend #coding #softwareengineering #asyncjavascript #closures #eventloop #codewithishwar

JavaScript Internals Most Developers Ignore

CodeWithIshwar — Wed, 29 Apr 2026 17:18:22 +0000

Most developers think they know JavaScript.

They don’t.

They know syntax…
but miss the real power behind it.

⚡ JavaScript isn’t powerful because of features

It’s powerful because of how it behaves under the hood

🧠 1. Functions are First-Class Citizens

You can pass, return, and store functions anywhere.

function greet(name) {
return Hello, ${name};
}

const sayHi = greet;
console.log(sayHi("Ishwar"));

👉 This is why callbacks, middleware, and hooks exist.

🔁 2. Closures (The Silent Superpower)

Functions remember their scope—even after execution.

function createCounter() {
let count = 0;

return function () {
count++;
return count;
};
}

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

👉 Used for:

Data privacy
Encapsulation
React hooks
⏳ 3. Event Loop (Non-Blocking Magic)

JavaScript is single-threaded but handles async efficiently.

console.log("Start");

setTimeout(() => console.log("Timeout"), 0);

Promise.resolve().then(() => console.log("Promise"));

console.log("End");

// Output:
// Start → End → Promise → Timeout

👉 Powered by:

Call stack
Callback queue
Microtask queue
🧩 4. Prototypal Inheritance

Objects inherit directly from other objects.

const animal = {
eat() {
console.log("eating");
},
};

const dog = Object.create(animal);
dog.bark = function () {
console.log("barking");
};

dog.eat();
dog.bark();

👉 Classes are just syntactic sugar over prototypes.

⚡ 5. Dynamic Typing & Coercion

Flexible—but can be tricky.

[] + {} // "[object Object]"
"5" - 2 // 3
"5" + 2 // "52"

👉 Understanding coercion prevents unexpected bugs.

🧠 6. Almost Everything is an Object
function fn() {}
typeof fn; // "function"

const arr = [1, 2, 3];
typeof arr; // "object"

(42).toFixed(2); // "42.00"

👉 Even primitives behave like objects via wrappers.

💡 What Most Developers Miss

JavaScript rewards understanding…
and punishes assumptions.

🚀 The Real Shift

Beginner:
“I know JavaScript syntax”

Advanced:
“I understand how JavaScript behaves”

🔥 Final Thought

Once you understand this:

You stop debugging blindly
You start predicting outcomes
💬 Let’s Discuss

What concept made JavaScript finally “click” for you?

🏷️ Tags

javascript #webdev #programming #frontend #coding #softwareengineering #asyncjavascript #closures #eventloop #codewithishwar

⚠️ Why a Simple Integer Breaks in Concurrency

CodeWithIshwar — Mon, 27 Apr 2026 17:07:51 +0000

A small example that completely changed how I think about shared state.

🧠 The Scenario

Consider a shared integer accessed by two threads:

Thread A increments (+1)
Thread B decrements (-1)

Expected

Actual

❌ Unpredictable

❗ The Hidden Problem

At first glance, this looks safe:

```java id="u3q9mp"
value++;




But this is **not atomic**.

It actually involves three steps:

1. Read
2. Modify
3. Write

Now imagine this execution order:



```id="s7k1ye"
Thread A → Read (0)
Thread B → Read (0)
Thread A → Write (1)
Thread B → Write (-1)

Final result: -1 instead of 0

⚠️ Race Condition

This is a race condition:

Multiple threads access shared data
At least one modifies it
No synchronization is applied

Result:

Inconsistent state
Unpredictable output
Subtle, hard-to-debug bugs

💻 Java Example

```java id="kz9r2a"
class Counter {
int value = 0;

void increment() {
    value++; // not atomic
}

void decrement() {
    value--; // not atomic
}

}

public class Main {
public static void main(String[] args) throws Exception {
Counter counter = new Counter();

    Thread t1 = new Thread(() -> {
        for (int i = 0; i < 10000; i++) counter.increment();
    });

    Thread t2 = new Thread(() -> {
        for (int i = 0; i < 10000; i++) counter.decrement();
    });

    t1.start();
    t2.start();

    t1.join();
    t2.join();

    System.out.println(counter.value); // ❌ unpredictable
}

}




---

## ✅ Approaches to Fix

### 1. synchronized

* Simple and reliable
* Ensures mutual exclusion
* ❌ Can reduce concurrency

---

### 2. AtomicInteger

* Lock-free
* Efficient for counters



```java id="6m2y8t"
import java.util.concurrent.atomic.AtomicInteger;

AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();

3. Locks (ReentrantLock)

Fine-grained control
Useful for advanced cases
❌ More complex

🌐 JavaScript Perspective

Even in JavaScript, async operations can introduce similar issues:

```javascript id="r4t8zn"
let counter = 0;

async function increment() {
let temp = counter;
await Promise.resolve();
counter = temp + 1;
}

async function decrement() {
let temp = counter;
await Promise.resolve();
counter = temp - 1;
}




---

## 🔐 Coordinating Async Access (Mutex Pattern)



```javascript id="g2w9xp"
class Mutex {
  constructor() {
    this.locked = false;
    this.queue = [];
  }

  lock() {
    return new Promise(resolve => {
      if (!this.locked) {
        this.locked = true;
        resolve();
      } else {
        this.queue.push(resolve);
      }
    });
  }

  unlock() {
    if (this.queue.length > 0) {
      const next = this.queue.shift();
      next();
    } else {
      this.locked = false;
    }
  }
}

🎯 Key Takeaway

Concurrency bugs rarely fail loudly.
They fail silently—and that’s what makes them dangerous.

🚀 Closing Thought

This small example highlights a deeper principle:

Shared state + concurrency = risk unless carefully managed.

🏷️ Suggested Tags

concurrency multithreading java javascript backend

📌 Author

Sharing practical backend learnings.

#CodeWithIshwar

⚠️ Why a Simple Integer Breaks in Concurrency (Race Condition Explained)

CodeWithIshwar — Mon, 27 Apr 2026 17:06:35 +0000

Even a simple shared integer can produce unpredictable results.

🧠 The Scenario

Let’s say we have a shared variable:

One thread increments (+1)
Another thread decrements (-1)

Expected result:

Actual result:

❌ Unpredictable

❗ What’s Going Wrong?

At first glance, this looks harmless:

value++;

But this is NOT atomic.

It actually involves three steps:

Read
Modify
Write

Now imagine two threads executing this at the same time:

Thread A → Read (0)
Thread B → Read (0)
Thread A → Write (1)
Thread B → Write (-1)

Final result: -1 instead of 0

⚠️ Race Condition

This is a classic race condition:

Multiple threads access shared data
At least one modifies it
No proper synchronization

Result:

Inconsistent data
Unpredictable behavior
Hard-to-debug issues

💻 Java Example

class Counter {
    int value = 0;

    void increment() {
        value++; // not atomic
    }

    void decrement() {
        value--; // not atomic
    }
}

public class Main {
    public static void main(String[] args) throws Exception {
        Counter counter = new Counter();

        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) counter.increment();
        });

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) counter.decrement();
        });

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println(counter.value); // ❌ unpredictable
    }
}

✅ Fixes

1. synchronized

Easy to use
Ensures mutual exclusion
❌ Can block threads

synchronized void increment() {
    value++;
}

2. AtomicInteger

Lock-free and efficient
Ideal for counters

import java.util.concurrent.atomic.AtomicInteger;

AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();

3. Locks (ReentrantLock)

More control
Useful for complex cases
❌ More verbose

🌐 JavaScript Version (Async Race Condition)

Even though JavaScript is single-threaded, async operations can still create race conditions:

let counter = 0;

async function increment() {
  let temp = counter;
  await Promise.resolve();
  counter = temp + 1;
}

async function decrement() {
  let temp = counter;
  await Promise.resolve();
  counter = temp - 1;
}

🔐 JavaScript Fix (Mutex)

class Mutex {
  constructor() {
    this.locked = false;
    this.queue = [];
  }

  lock() {
    return new Promise(resolve => {
      if (!this.locked) {
        this.locked = true;
        resolve();
      } else {
        this.queue.push(resolve);
      }
    });
  }

  unlock() {
    if (this.queue.length > 0) {
      const next = this.queue.shift();
      next();
    } else {
      this.locked = false;
    }
  }
}

🎯 Key Takeaway

Concurrency bugs don’t fail loudly.
They fail silently.

And that’s what makes them dangerous.

🚀 Final Thoughts

This small example completely changed how I think about shared state.

If you’re working in backend or distributed systems, this is something you must understand deeply.

🏷️ Tags (add on DEV)

#java #javascript #concurrency #backend #programming

📌 About Me

Sharing what I learn as I grow.

#CodeWithIshwar

Memory Is the Bottleneck We Notice Too Late

CodeWithIshwar — Mon, 20 Apr 2026 16:48:58 +0000

In many backend systems, performance issues are often blamed on CPU or inefficient logic.

But in practice, memory is frequently the real constraint.

The tricky part?

It doesn’t fail loudly.

⚠️ What I’ve Observed

Systems usually degrade gradually:

Increased response times
Random slowdowns
Occasional crashes under load

And when you investigate, it often traces back to memory usage patterns.

🚨 Common Patterns That Cause It

1. Over-fetching Data

// ❌ Loads everything into memory
const users = await getAllUsers();

Large Responses by Default

APIs returning more data than necessary increase both memory and network overhead.

Memory Leaks Long-lived references Uncleaned event listeners Open connections

These issues don’t show immediately but accumulate over time.

Lack of Caching

Repeated computation or database calls create unnecessary pressure.

🧠 A Small Shift That Helped Me

Instead of asking:

"How do I make this work?"

I started asking:

"Do I really need this in memory?"

That one question changed:

How I design APIs
How I fetch data
How I think about lifecycle
⚡ Why This Matters

Memory-efficient systems:

Stay stable under load
Scale more predictably
Are easier to debug
🤝 Open Question

How do you approach memory in your systems?

Do you actively design for it early,
or treat it as an optimization later?

Always curious to learn how others handle this.

— CodeWithIshwar | Ishwar Chandra Tiwari

🔥 Why this works on Forem

Feels like a community discussion, not a lecture
Includes real code + experience
Ends with a question → encourages replies
Fits open-source / dev culture tone

If you want next step:
I can help you turn all these into a consistent cross-platform content system so you don’t have to think every day.

Memory: The Silent Bottleneck in Backend Systems

CodeWithIshwar — Mon, 20 Apr 2026 16:44:31 +0000

🧠 Memory: The Silent Bottleneck in Backend Systems

When performance issues show up, most developers look at CPU or inefficient logic.

But in many real-world systems, the actual problem is memory usage.

🚨 Why Memory Matters

Memory issues don’t fail loudly.

Your system:

Works fine in development
Passes initial testing
Then starts slowing down under real traffic

That’s when memory becomes a bottleneck.

⚠️ Common Mistakes

1. Loading Too Much Data

// ❌ Bad
const users = await getAllUsers();

// ✅ Better

const users = await getUsers({ limit: 10 });

Large API Payloads

Sending unnecessary data increases:

Memory usage
Network latency

Fix: Return only required fields.

Memory Leaks

Objects that are not released properly keep consuming memory over time.

Example causes:

Unclosed connections
Global references
Event listeners not cleaned up

No Caching Strategy

Repeated heavy operations increase load.

// Example with caching
const cached = await redis.get("user:1");

if (!cached) {
  const data = await db.getUser(1);
  await redis.set("user:1", JSON.stringify(data));
}

⚡ Real Impact

Optimizing memory leads to:

Better performance
Fewer crashes
Improved scalability

🧠 Key Mindset

Most developers ask:

"How do I make this work?"

Better question:

"Do I really need this in memory?"

✅ Conclusion

Good engineers write code that works.
Great engineers write code that is efficient.

Memory may not be visible at first,

but it’s often the reason systems fail at scale.

💬 Have you faced memory issues in production?
Would love to hear your experience.

backend #systemdesign #performance #programming

🔥 Why this works on dev.to

Clean structure (important there)
Includes code examples
Practical, not motivational
Invites discussion

If you want next level:
I can turn this into a multi-part dev.to series (memory, caching, DB scaling, queues) so you grow faster as a backend creator.

You’re Probably Underestimating Redis

CodeWithIshwar — Fri, 17 Apr 2026 16:46:20 +0000

Redis Isn’t Just a Cache - It’s a Data Structure Engine

When I first started using Redis, I thought of it as just a fast key-value store.

But that’s only part of the story.

Under the hood, Redis is built on top of multiple powerful data structures:

Strings → simple key-value storage
Hashes → structured objects
Lists → queues and stacks
Sets → unique collections
Sorted Sets → ranking systems

Why This Design Matters

Each data structure is optimized for a specific type of problem.

This makes Redis incredibly versatile for use cases like:

caching
real-time leaderboards
job queues
session storage
analytics

The Bigger Lesson

The real takeaway isn’t just about Redis.

It’s about system design.

Good systems are not just fast —
they are built on choosing the right data structure for the problem.

Final Thought

Redis isn’t just a cache.

It’s a data structure engine that helps you think differently about solving problems.

#redis #dsa #systemdesign #backend #programming

Redis Isn’t Just a Cache - It’s a Data Structure Engine

CodeWithIshwar — Fri, 17 Apr 2026 16:44:03 +0000

At first, Redis looks like a simple key-value store.

But once you go deeper, you realize it’s built around multiple optimized data structures:

Strings → simple key-value
Hashes → object-like storage
Lists → queues / stacks
Sets → unique collections
Sorted Sets → ranking / leaderboards

Why This Matters

Each data structure is designed for a specific use case.

That’s why Redis is widely used for:

caching
real-time leaderboards
job queues
session storage
analytics

The Real Insight

The real power of Redis is not just speed.

It’s the ability to choose the right data structure for the problem.

Instead of thinking:

“Where do I store this?”

Start thinking:

“What structure fits this use case best?”

Conclusion

Redis is not just a cache.

It’s a data structure engine that helps you design better systems.

redis #dsa #systemdesign #backend #programming

🚨 Java & JavaScript Are NOT Call by Reference

CodeWithIshwar — Wed, 15 Apr 2026 17:16:28 +0000

This is one of those concepts that seems obvious… until it breaks your code.

Many developers believe:

“Objects are passed by reference in Java or JavaScript”

❌ That’s incorrect.

👉 Both Java and JavaScript are strictly call by value

🧠 Why This Feels Wrong

If you’ve ever done this:

function update(user):
    user.name = "Ishwar"

…and seen the change reflected outside,
it feels like pass by reference.

But then this:

function reset(user):
    user = new Object()

Does nothing to the original.

So what’s really going on?

⚙️ What’s Actually Happening

Variables store values
For objects → that value is a reference (memory address)

👉 When calling a function:

A copy of that value is passed
Not the original variable

🔍 The Key Insight

Inside the function:

You get a copy of the reference
Both point to the same object → mutation works
But reassignment only affects the local copy

🔁 Mental Model

original variable → copy value → function parameter

👉 You never get direct access to the original variable

📦 Stack vs Heap (Quick View)

Stack → variables (copies live here)
Heap → actual objects

👉 You copy the reference value, not the object

🌍 Applies Beyond Just Java

Language	Behavior
Java	Call by Value
JavaScript	Call by Value
Python	Call by Value (object ref)
C#	Call by Value (default)

💡 Final Takeaway

Everything is pass by value.
Some values just happen to be references.

🚀 Why This Matters

This concept shows up in real-world bugs:

Unexpected object mutations
State issues in frontend apps
Backend data inconsistencies
API transformation bugs

🤔 Discussion

When did this finally click for you?

Early learning phase
On the job
Or after debugging something painful 😅

Built for devs who like understanding why, not just what.
More deep dives coming.

🚨 Java & JavaScript Are NOT Call by Reference (Let’s Break This Myth)

CodeWithIshwar — Wed, 15 Apr 2026 17:14:43 +0000

One of the most common misconceptions in programming:

“Objects are passed by reference in Java or JavaScript”

❌ That’s not true.

👉 Both Java and JavaScript are call by value

🧠 Why the Confusion?

Because when you pass objects into a function, changes sometimes reflect outside.

That behavior feels like call by reference… but it’s not.

⚙️ What Actually Happens

Every variable stores a value
For primitives → actual data
For objects → memory address (reference)

👉 During a function call:
➡️ A copy of that value is passed

🔍 Two Cases That Explain Everything

✅ Case 1: Mutation (Works)

function change(user) {
  user.name = "Ishwar"; // ✅ affects original
}

✔️ Both variables point to the same object in memory
✔️ Changes are visible

❌ Case 2: Reassignment (Does NOT Work)

function reassign(user) {
  user = { name: "New" }; // ❌ does NOT affect original
}

❌ Only the local copy changes
❌ Original remains unchanged

⚙️ The Algorithm Behind It

Variable stores a value
Function is called
A new stack frame is created
Parameters receive copy of argument values
Function works on copied values
Stack frame is destroyed

🔁 Mental Model

Caller Variable → Copy Value → Function Parameter

👉 No direct access to original variable
👉 Only a copy is used

📦 Stack vs Heap (Simple View)

Stack → variables (copies live here)
Heap → actual objects

👉 You copy the reference value, not the object

🌍 Applies to Multiple Languages

Language	Behavior
Java	Call by Value
JavaScript	Call by Value
Python	Call by Value (object ref)
C#	Call by Value (default)

💡 Final Rule

“Everything is pass by value.
Some values just happen to be references.”

🚀 Why This Matters

This concept helps avoid bugs in:

Backend APIs
State management (React, Redux)
Object mutation issues
System design

🤔 Question for You

When did this concept finally click for you?

College?
First job?
Or after debugging a weird bug? 😅

💬 If this helped, drop a comment or share with someone who still thinks it's call by reference 😉

#java #javascript #programming #coding #softwareengineering #webdev #beginners #devtips

Limitations of System Design with Real-World Examples

CodeWithIshwar — Mon, 13 Apr 2026 17:50:07 +0000

System design looks clean in theory.

But real systems are built on trade-offs.

1. No Design is Future-Proof

Netflix started with a monolith and later moved to microservices as scale increased.

2. Trade-offs are Unavoidable

Amazon often prefers availability over strict consistency.

Users may see "Order Placed" even if systems are still syncing.

3. Over-Engineering Slows You Down

Microservices too early can slow development.

4. Assumptions Fail

Uber had to redesign systems as demand patterns changed.

5. Cost vs Performance

Better performance requires more infrastructure cost.

6. Complexity Increases with Scale

More services lead to more failures and harder debugging.

Final Thought

There is no perfect system design. Only trade-offs.

Limitations of System Design (with Real-World Examples)

CodeWithIshwar — Mon, 13 Apr 2026 17:48:26 +0000

System design often looks clean in theory — neat diagrams, scalable architectures, and well-defined components.

But in real-world systems, things are rarely that simple.

Every design decision comes with trade-offs.

🚫 1. No Design is Future-Proof

Systems evolve with scale.

Example:
Netflix started with a monolithic architecture and later moved to microservices as its user base grew.

Takeaway: Design for current needs, but expect change.

⚖️ 2. Trade-offs Are Unavoidable

You cannot optimize everything at once.

Example:
Amazon often prioritizes availability over strict consistency. Users may see "Order Placed" even when backend systems are still syncing.

Takeaway: User experience > perfect consistency (sometimes).

⚡ 3. Over-Engineering Slows You Down

Microservices are powerful—but not always necessary.

Common mistake:
Teams adopt microservices too early, increasing complexity and slowing development.

🔄 4. Assumptions Don’t Hold Forever

System design relies on assumptions:

Traffic patterns
User behavior
Growth

Example:
Uber had to redesign parts of its system as demand patterns evolved.

💰 5. Cost vs Performance

Improving performance comes at a cost:

Caching
CDNs
Replication

Better performance = higher cost.

🧩 6. Complexity Increases with Scale

As systems grow:

More services
More communication
More failure points

Debugging distributed systems is harder than building them.

🎯 Final Thoughts

There is no perfect system design.

Only trade-offs, constraints, and context.

👉 Design for today. Prepare for tomorrow.

💬 Discussion

What’s one system design challenge you’ve faced?