DEV Community: Shajibul Alam Shihab

Understanding Stack vs Heap Memory (The Way Every Beginner Wishes It Was Explained)

Shajibul Alam Shihab — Sun, 26 Jul 2026 09:05:32 +0000

If you've been learning programming for a while, you've probably heard terms like Stack Memory, Heap Memory, Call Stack, or maybe even Stack Overflow.

At first, these terms sound scary.

When I was learning programming, I remember thinking:

"Why do I even need to know this? Can't I just write code?"

The answer is... you absolutely can.

In fact, many developers write code for months even years without fully understanding how memory works behind the scenes.

But sooner or later, you'll run into questions like these:

Why do local variables disappear after a function finishes?
Why do objects still exist even after the function that created them has returned?
Why does infinite recursion crash the program?
What exactly is a memory leak?

Interestingly, all of these questions are connected. And the answer starts with understanding how your program uses memory. Don't worry we're not going to dive straight into complicated computer science terms. Instead, we'll build the idea step by step.

By the end of this article, you'll understand:

✅ What the Stack is
✅ What the Heap is
✅ Why programming languages use both
✅ How functions use memory
✅ Why stack overflows happen
✅ Why memory leaks happen
✅ And how all of these concepts connect together

Our goal isn't just to memorize definitions. It's to build a mental picture of what's happening every time your code runs.

So let's start with a simple question.

When you call a function, where does the computer actually keep everything that function needs?

Before We Talk About the Stack...

Let's look at a simple function.

function greet(name: string) {
    const message = `Hello, ${name}`;
    console.log(message);
}

greet("Alex");

This looks like a very small piece of code. But when you run it, the computer has to keep track of several things.

For example:

It needs to remember that name is "Alex".
It needs somewhere to store the message variable.
It needs to know which line of code it should execute next after the function finishes.

All of this information has to live somewhere while the function is running.

Now imagine your program calling hundreds of functions every second.

The computer needs a system that can:

quickly create memory for a new function,
keep each function's data separate,
and remove that memory as soon as the function is done.

If this process were slow, every program you wrote would become slower too. So instead of placing function data randomly in memory, computers use a very organized system. That system is called the Call Stack.

Before we understand the Call Stack, though, we first need to understand one simple idea.

What exactly is a stack?

What Is a Stack?

Before we talk about the Call Stack, let's first understand what a stack actually is.

Imagine you have a stack of plates in your kitchen.

When you add a new plate, you place it on top.

When you need a plate, you also take it from the top.

You never remove the plate from the middle because that would make the whole stack unstable.

It looks something like this:

This is exactly how a stack works.

You always add new items to the top.

You always remove items from the top.

Because the last item added is also the first item removed, a stack follows a rule called Last In, First Out (LIFO).

Don't worry too much about remembering the name.

Just remember the idea:

The most recently added item is always the first one to leave.

That's all a stack is.

Now let's see how this idea is used when a program runs.

Introducing the Call Stack

Every time your program calls a function, the computer places that function on top of the Call Stack.

Let's look at a simple example.

function greet(name: string) {
    console.log(`Hello, ${name}`);
}

greet("Alex");

When greet("Alex") is called, the computer creates a small workspace for that function. This workspace contains everything the function needs while it's running.

Instead of putting that workspace somewhere random in memory, the computer pushes it onto the top of the Call Stack.

You can imagine it like this:

At this moment, greet() is the only function that's running, so it's the only frame on the stack.

Once the function finishes, the computer removes it from the top.

The memory used by that function is immediately available to be reused for the next function call. This happens automatically. You don't have to clean anything up yourself.

Every function call follows this same pattern:

The function is called.
A new frame is pushed onto the Call Stack.
The function runs.
The frame is popped from the Call Stack when the function finishes.

This happens so quickly that we never notice it, but it's happening every time a function is called.

What Is a Stack Frame?

Earlier, I mentioned that the computer creates a workspace for every function.

That workspace has a proper name: A stack frame.

A stack frame is simply the memory that belongs to one specific function call.

For example:

function add(a: number, b: number): number {
    const sum = a + b;
    return sum;
}

When add(5, 10) runs, the computer creates a stack frame that stores things like:

the value of a
the value of b
the local variable sum
information about where the program should continue after the function returns

You can picture it like this:

Think of a stack frame as a temporary workspace. It exists only while the function is running. As soon as the function returns, the entire frame is removed from the stack. That also means the local variable sum disappears because the workspace that owned it no longer exists.

This is why we say that stack memory is temporary. It's created when a function starts, and it's automatically cleaned up when the function finishes. And because every function gets its own stack frame, different function calls never accidentally overwrite each other's local variables.

Why Is the Stack So Fast?

By now, you know that every function call gets its own stack frame.

When the function starts, a new frame is added to the top of the Call Stack.

When the function finishes, that frame is removed.

But here's something interesting:

This process is incredibly fast.

In fact, allocating memory on the stack is one of the fastest memory operations a program can perform.

So... what makes it so fast?

The answer lies in how the stack is organized.

The Stack Is Highly Organized

Think about a stack of books.

When you want to add a new book, where do you put it?

On the top.

When you want to remove one, which book do you take?

Again, the one on the top.

You never search through the stack looking for an empty spot. You never rearrange the books. You always work with the top.

The Call Stack follows the exact same idea.

When a function is called, its stack frame is simply placed on top of the previous one. When the function returns, that top frame is removed.

That's it.

The computer always knows exactly where the next stack frame should go and exactly which frame should be removed. It never has to search for free memory. It never has to reorganize anything. Everything happens in a predictable order.

A Simple Way to Think About It

Imagine you have a notebook.

Every time a function is called, you write its information on the next empty page.

When that function finishes, you simply tear out the last page.

Then the next function can use that page again.

You don't have to flip through the notebook looking for empty pages.

You don't have to erase individual lines.

You just move forward when a function starts and move backward when it ends.

This is very similar to how stack memory works.

Stack Allocation Is Just Moving a Pointer

Here's a fun fact that surprises many beginners.

When people hear "allocate memory," they often imagine the computer doing a lot of work.

But for stack memory, that's usually not the case.

Internally, the program keeps track of the top of the stack using something called the stack pointer.

You don't need to know all the low-level details, but here's the basic idea.

Imagine the stack currently looks like this:

Now suppose another function is called.

The computer doesn't search for a place to store it.

It simply moves the stack pointer and places the new frame on top.

When Function C finishes, the stack pointer moves back.

Notice something important.

The computer didn't need to clean every variable one by one. It didn't need to erase memory. It simply moved the pointer back.

From the program's point of view, that memory is now free to be reused. That's why stack allocation is so fast.

Automatic Cleanup

Another big advantage of the stack is that it cleans itself up automatically.

Let's look at this example again.

function add(a: number, b: number): number {
    const sum = a + b;
    return sum;
}

While the function is running, the stack frame contains something like this:

add()

a = 5
b = 10
sum = 15

As soon as the function returns, the entire frame disappears.

You don't have to write code to remove a.

You don't have to delete b.

You don't have to free sum.

Everything inside that stack frame is removed together because it all belongs to the same function call.

This is one of the reasons why local variables are so convenient to use.

Their lifetime is automatically managed by the Call Stack.

But There's One Limitation...

At this point, the stack sounds almost perfect.

It's fast.

It's simple.

It cleans itself up automatically.

So why doesn't the computer store everything on the stack?

The answer is that the stack has one important limitation.

Everything on the stack must have a short and predictable lifetime.

Think about a function that creates a user object and returns it.

function createUser() {
    const user = {
        name: "Ada"
    };

    return user;
}

The function finishes almost immediately.

If the object lived entirely on the stack, it would disappear the moment the function returned.

But that would make the returned object useless because the caller still wants to use it.

So where should that object live instead?

This question leads us to the second major area of memory:

The Heap.

The Problem the Stack Can't Solve

So far, the Stack sounds almost perfect. It's incredibly fast. It automatically cleans up memory. And every function gets its own temporary workspace.

At this point, you might be wondering:

"If the Stack works so well, why do we even need the Heap?"

That's a great question.

The answer is simple.

The Stack is designed for temporary data. Sometimes, that's exactly what we want.

But sometimes...

We need data to live much longer than the function that created it.

Let's see what that means.

A Simple Example

Imagine we have a function that creates a user.

function createUser() {
    const user = {
        name: "Ada",
        age: 28
    };

    return user;
}

const person = createUser();

console.log(person.name);

When you first look at this code, it seems completely normal.

The function creates an object.

The object is returned.

Then we use it outside the function.

Nothing surprising here.

But let's stop and think about what's actually happening.

What Happens When the Function Returns?

Earlier, we learned that when a function finishes, its stack frame is removed.

That means every local variable inside that function disappears.

In this example, that includes the local variable user.

So after createUser() returns, the stack frame is gone.

Before returning:

After returning:

So here's the question.

If the stack frame has disappeared...

How is this still working?

console.log(person.name);

Where is the object?

If everything inside the function disappeared, shouldn't the object disappear too?

The answer is no.

And this is exactly why the Heap exists.

Meet the Heap

The Heap is another area of memory that is designed for data that needs to live longer than a single function call.

Unlike the Stack, the Heap is not automatically cleaned up when a function returns.

Instead, data stored in the Heap stays alive for as long as your program still needs it.

In JavaScript, things like:

objects
arrays
functions
maps
sets

are all stored in the Heap.

Why?

Because their lifetime is often unpredictable.

Sometimes an object lives for just a few milliseconds.

Sometimes it stays alive for the entire lifetime of your application.

The computer doesn't know that in advance.

So it stores these values in a place where they can stay alive for as long as necessary.

The Stack Doesn't Store the Entire Object

Here's a detail that surprises many beginners.

When you write this:

const user = {
    name: "Ada"
};

Most people imagine that the variable user contains the entire object.

But that's not quite what happens.

Instead, the object itself is stored in the Heap.

The variable user simply stores a reference to that object.

You can imagine it like this.

Think of a reference like a home address.

Imagine your friend lives at:

25 Maple Street

If you write that address on a piece of paper, the paper isn't the house.

It simply tells you where the house is.

A reference works in a similar way.

The variable doesn't contain the entire object.

It simply knows where the object is stored.

Now Everything Makes Sense

Let's go back to our example.

function createUser() {
    const user = {
        name: "Ada"
    };

    return user;
}

const person = createUser();

While createUser() is running, the stack might look something like this:

When the function returns, something interesting happens.

The local variable user disappears because its stack frame is removed.

But before the frame disappears, the reference is returned to the caller.

Now another variable, person, points to the very same object.

The function is gone.

The original variable is gone.

But the object is still alive because something still references it.

And that's the key idea to remember.

Objects don't stay alive because the function that created them still exists. They stay alive because something can still reach them.

Once you understand this idea, a lot of JavaScript starts making more sense.

For example:

why objects can be shared,
why changing an object through one variable affects another,
and how garbage collection knows when an object can finally be removed.

We'll look at that next.

If Objects Stay in Memory... Won't Memory Keep Filling Up?

Now we know something important.

Objects stored in the Heap don't disappear just because a function finishes.

Instead, they stay alive as long as they're still being used.

But that raises another question.

Imagine your program creates thousands of objects every minute.

function createUser(name: string) {
    return {
        name
    };
}

Every time this function runs, a new object is created.

const user1 = createUser("Alice");
const user2 = createUser("Bob");
const user3 = createUser("Charlie");

If these objects stay in memory after the function returns...

Wouldn't your computer eventually run out of memory?

Fortunately, the answer is no.

And that's because of something called Garbage Collection.

What Is Garbage Collection?

Garbage Collection is a process that automatically removes objects from the Heap when they're no longer needed.

Think of it like a cleaning service.

Imagine you move out of an apartment.

As long as someone is still living there, the apartment stays occupied.

But once everyone moves out, the apartment becomes empty.

Eventually, someone comes along, cleans it, and makes it available for the next tenant.

Garbage Collection works in a similar way.

It doesn't remove objects immediately.

Instead, from time to time, JavaScript checks which objects are still reachable.

If an object can no longer be reached by your program, it becomes garbage.

The Garbage Collector can safely remove it and reuse that memory later.

The Most Important Word: Reachable

When people first learn about Garbage Collection, they often think:

"Objects are deleted when a function ends."

That's not true.

The real rule is much simpler.

An object stays alive as long as your program can still reach it.

Let's see what that means.

let user = {
    name: "Ada"
};

Right now, the object is alive because the variable user points to it.

Now suppose we do this:

user = null;

What happened?

The variable no longer points to the object.

At this point, nothing in our program knows where that object is anymore.

No variable points to it.

No array contains it.

No object references it.

It has become unreachable.

Since the program can never use that object again, the Garbage Collector is free to remove it from memory.

Notice something important.

The object wasn't removed because we wrote null.

It became removable because nothing references it anymore.

That's a very important difference.

Garbage Collection Doesn't Run Immediately

Here's another common misunderstanding.

Some beginners think that as soon as an object becomes unreachable, JavaScript instantly deletes it.

That's not how it works.

Garbage Collection runs from time to time while your program is running.

When it runs, it looks for objects that are no longer reachable.

Then it cleans them up.

Exactly when this happens depends on the JavaScript engine.

As developers, we don't control it.

And most of the time, we don't need to.

Our job is simply to stop referencing objects that we no longer need.

The JavaScript engine takes care of the rest.

How Is This Different From C?

JavaScript makes memory management much easier.

But not every programming language works this way.

In the C programming language, the programmer is responsible for managing heap memory manually.

When you allocate memory, you must also remember to free it later.

If you forget, that memory stays allocated even though your program no longer needs it.

This is called a memory leak.

Imagine checking into a hotel and never checking out.

Even if nobody is using the room anymore, nobody else can use it either.

The room stays occupied until someone finally clears it.

That's similar to what happens with a memory leak.

The memory exists.

But it's no longer doing anything useful.

Does JavaScript Have Memory Leaks?

At this point, you might think:

"Since JavaScript has Garbage Collection, memory leaks can't happen."

Unfortunately, they still can.

Remember the rule:

Garbage Collection only removes objects that are unreachable.

If your program accidentally keeps a reference to an object that it no longer needs, the Garbage Collector assumes you're still using it.

So it leaves the object in memory.

For example:

const users = [];

function createUser(name: string) {
    users.push({
        name
    });
}

Every time this function runs, a new object is added to the users array.

As long as that array exists, every object inside it is still reachable.

Even if you never use those objects again, the Garbage Collector cannot remove them because your program still has a reference to them.

This is one of the most common reasons memory leaks happen in JavaScript.

Not because the Garbage Collector failed...

But because our code accidentally kept references that were no longer needed.

The Big Idea

At first, it might seem like the Garbage Collector magically knows which objects to delete.

But the idea is actually much simpler.

It asks one question:

"Can the program still reach this object?"

If the answer is yes, the object stays.

If the answer is no, the object can eventually be removed.

Everything else about Garbage Collection builds on this single idea.

Once you understand reachability, you've already understood one of the most important concepts in memory management.

When Things Go Wrong: Stack Overflow vs Memory Leak

Now that we understand how the Stack and the Heap work, let's look at two very common memory-related problems.

Although they both involve memory, they're completely different.

A Stack Overflow happens because the Stack runs out of space.
A Memory Leak happens because the Heap keeps holding memory that is no longer needed.

Let's understand them one at a time.

Stack Overflow

Earlier, we learned that every function call creates a new stack frame.

When the function finishes, that frame is removed.

Normally, this works perfectly.

For example, consider this function:

function greet(name: string) {
    console.log(`Hello, ${name}`);
}

greet("Alex");

The sequence looks like this:

The Stack grows a little while the function is running, then immediately shrinks again.

No problem.

But What If the Function Never Stops Calling Itself?

Now let's look at a different example.

function recurseForever(n: number): number {
    return recurseForever(n + 1);
}

recurseForever(0);

At first, nothing looks unusual.

The function calls itself.

Then it calls itself again.

And again.

Each call creates a new stack frame.

Notice something important.

None of these function calls can finish yet.

Each one is waiting for the next call to return.

So none of the stack frames can be removed.

The Stack keeps growing.

Eventually, it reaches its maximum size.

When that happens, JavaScript throws an error similar to this:

RangeError:
Maximum call stack size exceeded

This is called a Stack Overflow.

The program didn't run out of RAM.

It simply ran out of Stack space.

The Problem Isn't Recursion

Many beginners hear about Stack Overflow and think:

"So recursion is bad."

Not at all.

Recursion is a perfectly valid programming technique.

The real problem is recursion without a reachable stopping condition.

Let's compare two examples.

This one is safe:

function countdown(n: number) {
    if (n === 0) {
        return;
    }

    countdown(n - 1);
}

countdown(5);

Eventually, n becomes 0.

The function stops calling itself.

Each stack frame returns.

The Stack becomes empty again.

Everything works correctly.

Now compare that with this:

function recurseForever(n: number): number {
    return recurseForever(n + 1);
}

There is no stopping condition.

The function keeps creating new stack frames forever.

That's why the Stack overflows.

So the issue isn't recursion itself.

The issue is never giving recursion a chance to end.

Memory Leaks

Stack Overflow happens because the Stack fills up.

Memory leaks are different.

They happen in the Heap.

Remember what we learned about Garbage Collection.

An object stays alive as long as something still references it.

Now imagine we accidentally keep references to objects that we no longer need.

const users = [];

function createUser(name: string) {
    users.push({
        name
    });
}

Every time this function runs, another object is added to the array.

createUser("Alice");
createUser("Bob");
createUser("Charlie");

The array keeps growing.

users

↓

[
  { name: "Alice" },
  { name: "Bob" },
  { name: "Charlie" }
]

If we never remove these objects, they stay reachable through the users array.

That means the Garbage Collector cannot remove them.

If this continues for a long time, the application uses more and more memory.

This is called a memory leak.

Why It's Called a "Leak"

Think of a water tank.

You keep pouring water into it.

But nothing ever comes out.

Eventually, the tank becomes full.

A memory leak is similar.

Your program keeps allocating memory.

But because old objects are still being referenced, that memory is never released.

Over time, memory usage keeps growing.

A Quick Comparison

Although Stack Overflow and Memory Leak are both related to memory, they happen for completely different reasons.

Stack Overflow	Memory Leak
Happens in the Stack	Happens in the Heap
Usually caused by very deep or infinite recursion	Usually caused by keeping references to objects you no longer need
Happens quickly	Often happens slowly over time
Crashes the program immediately	Gradually increases memory usage
Solved by reducing recursion or using iteration	Solved by removing unnecessary references

Understanding this difference is important because the solutions are completely different.

If your Stack overflows, adding more RAM won't help.

If your application has a memory leak, fixing recursion won't help either.

The first problem is about running out of stack space.

The second is about holding onto heap memory longer than necessary.

Knowing which problem you're dealing with is the first step toward fixing it.

Common Misunderstandings About Stack and Heap

By now, you've learned how the Stack and the Heap work together.

But there are a few misunderstandings that almost every beginner has at some point.

Let's clear them up.

❌ "Everything inside a function disappears when the function returns."

This is probably the most common misunderstanding.

Let's look at this example again.

function createUser() {
    const user = {
        name: "Ada"
    };

    return user;
}

const person = createUser();

At first glance, it seems like everything inside createUser() should disappear after the function finishes.

And that's partly true.

The variable user disappears because it belongs to the function's stack frame.

But the object doesn't disappear.

Why?

Because the object lives in the Heap, and the variable person now holds a reference to it.

You can picture it like this:

The function is gone.

The original variable is gone.

But the object is still reachable.

And as long as it's reachable, it stays alive.

This is an important distinction.

Variables can disappear while the objects they point to continue to exist.

❌ "Primitive values are always on the Stack, and objects are always on the Heap."

You'll often hear people say this online.

It's a useful simplification when you're first learning, but it's not the complete story.

In JavaScript, it's helpful to think this way because it matches how the language behaves from a developer's point of view.

However, modern JavaScript engines are highly optimized.

They can sometimes store or optimize values differently behind the scenes.

The important thing to remember isn't where every byte lives.

The important thing is understanding how values behave.

For beginners, this mental model works well:

Primitive values behave like simple values.
Objects and arrays behave like references to data that can outlive the current function.

As you learn more about JavaScript engines like V8, you'll discover that the implementation is more complex.

But for now, this model is exactly what you need.

❌ "Garbage Collection removes objects immediately."

This is another very common misconception.

Imagine you do this:

let user = {
    name: "Ada"
};

user = null;

The object has become unreachable.

Does JavaScript delete it immediately?

Not necessarily.

The Garbage Collector runs from time to time while your program is running.

When it runs, it looks for unreachable objects and removes them.

So it's better to think of Garbage Collection like a cleaning service.

The room becomes empty first.

The cleaner comes later.

❌ "Recursion is bad."

After learning about Stack Overflow, some people become afraid of recursion.

But recursion itself isn't the problem.

Many algorithms are naturally recursive, such as:

traversing a file system,
exploring a tree,
walking through nested JSON,
or solving divide-and-conquer problems.

The real problem is recursion that never reaches a stopping condition or recursion that's much deeper than the available stack space.

A well-written recursive function is just as valid as an iterative one.

The important thing is knowing when each approach is appropriate.

A Special Note for C and C++ Developers

If you're learning JavaScript, you don't have to worry about this section right away.

But if you ever move to languages like C or C++, there's one mistake you'll hear about very often.

Returning a pointer to a local stack variable.

For example:

int* getNumber() {
    int value = 42;
    return &value; // ❌ Dangerous
}

At first, this might seem reasonable.

The function returns the address of value.

But remember what happens when a function finishes.

Its stack frame is removed.

That means value no longer exists.

The returned pointer now points to memory that is no longer valid.

This is called a dangling pointer.

Trying to use that pointer later leads to undefined behavior, which means the program could:

appear to work,
produce incorrect results,
or crash completely.

Fortunately, JavaScript developers never deal with dangling pointers because memory management is handled automatically.

Still, this example highlights an important idea that applies to every language:

Data stored in a function's stack frame cannot outlive that function.

That's one of the main reasons long-lived data belongs in the Heap instead of the Stack.

The Mental Model You Should Remember

After everything we've discussed, Stack and Heap memory might still feel like a lot of different pieces.

So let's put everything together into one simple mental model.

Imagine your program is running.

A function gets called.

What happens?

Step 1: A Function Call Creates a Stack Frame

Every time a function starts, the program creates a new stack frame.

That frame stores information that belongs only to that function:

function parameters,
local variables,
and the place where the program should continue afterward.

Example:

function calculateTotal(price: number, tax: number) {
    const total = price + tax;
    return total;
}

While this function runs, the Stack contains its temporary workspace.

When the function finishes, the frame disappears.

The Stack cleans itself automatically.

Step 2: Objects Need a Longer Home

Now imagine the function creates an object.

function createAccount() {
    return {
        username: "alex"
    };
}

The object needs to survive after the function finishes.

So the object is stored in the Heap.

The Stack keeps only a reference to it.

The reference can disappear.

The object can continue living.

As long as something can still reach that object, it stays alive.

Step 3: Garbage Collection Cleans Unused Objects

Eventually, an object may no longer be needed.

For example:

let account = {
    username: "alex"
};

account = null;

Now nothing points to that object.

It becomes unreachable.

The Garbage Collector can later remove it.

The important rule:

Memory is not cleaned because a function ends. Memory is cleaned when data is no longer reachable.

Step 4: Problems Happen When We Break These Rules

Understanding the rules also helps us understand common problems.

Stack Overflow

The Stack has limited space.

If functions keep calling themselves forever:

function forever() {
    forever();
}

New stack frames keep getting added.

Eventually:

Stack space exceeded

The program crashes because the Stack cannot grow anymore.

Memory Leak

The Heap can hold a lot of data.

But if your program accidentally keeps references to objects it no longer needs, those objects cannot be removed.

Example:

const cache = [];

function saveData(data) {
    cache.push(data);
}

If cache keeps growing forever, old objects remain reachable.

The Garbage Collector cannot clean them.

Memory usage keeps increasing.

That's a memory leak.

Stack vs Heap: The Big Picture

Let's compare them one final time.

	Stack	Heap
Purpose	Temporary function data	Long-lived dynamic data
Stores	Stack frames, local values	Objects, arrays, complex data
Speed	Very fast	Slower
Management	Automatically removed when functions return	Removed when no longer reachable (or manually freed in some languages)
Size	Smaller and limited	Much larger
Common problem	Stack Overflow	Memory Leak

The One Thing I Want You to Remember

If you remember only one idea from this article, remember this:

The Stack manages the short life of functions. The Heap manages the longer life of data.

Functions come and go.

Stack frames are created and destroyed quickly.

Objects often need to stay around longer.

That's why we need two different memory areas.

The Stack gives us speed and automatic cleanup.

The Heap gives us flexibility and longer lifetimes.

Neither one is better.

They solve different problems.

Final Thoughts

Understanding Stack and Heap won't immediately change how you write code every day.

You can write many programs without thinking about memory at all.

But once you understand what's happening underneath, many confusing programming concepts become much clearer:

Why local variables disappear.
Why objects survive function calls.
Why recursion can crash a program.
Why memory leaks happen.
Why garbage collection exists.
Why some languages require manual memory management.

Programming becomes much easier when you stop seeing memory as magic.

Behind every function call, every object, and every variable, there is a simple system working quietly in the background.

And now you understand how that system works. 🚀

Strings look simple... until they surprise you.

Shajibul Alam Shihab — Tue, 21 Jul 2026 06:05:33 +0000

Strings & Text Processing: Text Isn't as Simple as It Looks

If someone asks you what's the simplest type of data in programming, there's a good chance you'll say strings.

After all, they're just text.

A person's name is a string.

An email address is a string.

A password is a string.

Even the message you're reading right now is just a collection of strings.

At first glance, there doesn't seem to be much to learn. You create a string, print it, compare it with another string, and move on.

But after writing a few programs, things start getting... strange.

You convert "hello" into uppercase, yet the original string somehow stays the same.

An emoji that looks like a single character suddenly reports a length of 2.

Joining thousands of small strings together makes your program unexpectedly slower.

And then someone introduces you to something called Regex, which looks less like code and more like an ancient spell.

None of these are bugs. They're simply the result of how strings actually work behind the scenes.

In this lesson, we'll uncover those hidden details one by one.

Surprise #1: Why Didn't the String Change?

Take a look at this code.

const original = "hello";
const shouted = original.toUpperCase();

console.log(original);
console.log(shouted);

What would you expect the output to be?

Many beginners think the output will look like this:

HELLO
HELLO

But that's not what happens.

Instead, JavaScript prints:

hello
HELLO

The original string remains exactly as it was.

Why?

Because strings are immutable.

What Does "Immutable" Mean?

The word immutable simply means:

Once something is created, it cannot be changed.

Think of a printed book.

If you want every occurrence of the word hello to become HELLO, you don't magically change the ink that's already on the paper.

Instead, you print a new copy with the updated text.

Strings behave in a similar way.

Whenever you use methods like:

toUpperCase()
toLowerCase()
replace()
concat()

the original string stays untouched.

Instead, JavaScript creates a brand-new string and returns it.

That's why this works:

const original = "hello";
const shouted = original.toUpperCase();

Instead of modifying original, JavaScript creates another string containing "HELLO" and stores it inside shouted.

This behavior isn't unique to JavaScript.

Python, Java, C#, and many modern programming languages treat strings the same way.

Why Design Strings This Way?

At first, immutability sounds like an unnecessary restriction.

Why not simply change the existing string?

Because immutable data is much safer.

Imagine two different parts of your program are using the same string.

If one part secretly changes it, the other part suddenly starts seeing different data, which can lead to bugs that are extremely difficult to track down.

By making strings immutable, programming languages guarantee that once a string is created, nobody can unexpectedly modify it.

Whenever a change is needed, a completely new string is created instead.

It might seem like a small design decision, but it prevents countless bugs in large applications.

A Hidden Cost of Creating New Strings

Creating new strings is usually so fast that you never notice it.

But imagine doing it thousands or even millions of times.

Consider this loop:

let result = "";

for (const word of ["JavaScript", "is", "awesome"]) {
    result += word;
}

The code looks perfectly reasonable.

But here's what's happening behind the scenes.

Initially:

""

After the first iteration:

"JavaScript"

The old empty string is discarded.

Next iteration:

"JavaScriptis"

The previous string is discarded again.

Then:

"JavaScriptisawesome"

Another new string is created.

Even though we only care about the final result, JavaScript had to create multiple temporary strings along the way.

For three words, that's not a problem.

For three million words, it becomes expensive.

The Better Approach

When building large pieces of text, programmers usually avoid repeatedly using +=.

Instead, they collect all the pieces first.

const parts = [];

for (const word of ["JavaScript", "is", "awesome"]) {
    parts.push(word);
}

const result = parts.join("");

Instead of constantly creating new strings, we simply store each word inside an array.

Only at the very end do we combine everything into one final string.

This creates far fewer temporary objects and is generally much more efficient when working with large amounts of text.

That doesn't mean you should never use +=.

For small strings, it's perfectly fine and often easier to read.

But when performance matters or when you're building very large strings inside loops collecting pieces first and joining them later is the better approach.

Strings Seem Simple... Until They Aren't

So far, we've learned two important things.

First, strings never change after they're created.

Second, every "modification" actually creates a completely new string.

Most of the time, that's all you need to know.

But then something even stranger happens.

You write this:

"😀".length

And JavaScript replies:

Not 1.

How can a single emoji have a length of two?

To answer that, we need to look beyond strings themselves and understand how computers store text in memory.

Surprise #2: Why Does One Emoji Have a Length of 2?

At first, this feels like a bug.

You can clearly see one emoji.

"😀".length

Yet JavaScript says:

How can one visible character suddenly become two?

The answer has nothing to do with emojis.

It has everything to do with how computers store text.

Computers Don't Understand Letters

When you type the letter:

you see a character.

But your computer doesn't.

Computers only understand numbers.

So before any text can be stored, every character must first be converted into numbers.

This conversion is called text encoding.

Think of encoding as a giant dictionary.

Instead of storing the actual letter A, the computer stores a number that represents A.

When it reads that number again, it knows to display the letter A on your screen.

The same idea works for every language.

Whether it's English,

Hello

Arabic,

مرحبا

Japanese,

こんにちは

or Bengali,

হ্যালো

they're all stored as numbers behind the scenes.

Enter UTF-8

Years ago, computers mostly dealt with English text.

A simple encoding called ASCII was enough because it only needed to represent English letters, digits, and a few symbols.

But the internet changed everything.

Suddenly, computers needed to store text from almost every language in the world.

Not just that they also needed to support symbols, currency signs, mathematical operators, and eventually emojis.

That's why modern software largely uses an encoding called UTF-8.

UTF-8 is clever.

Instead of giving every character the same amount of storage, it uses only as much space as needed.

For example:

Most English letters use 1 byte.
Many accented characters use 2 bytes.
Some Asian characters use 3 bytes.
Many emojis use 4 bytes.

This keeps English text compact while still allowing virtually every written language to be represented.

Then Why Does JavaScript Say 2?

Here's the confusing part.

Even though UTF-8 is the most common encoding for storing and transmitting text, JavaScript doesn't use UTF-8 to calculate .length.

Instead, JavaScript stores strings internally using UTF-16.

And .length doesn't count "characters" the way humans see them.

It counts UTF-16 code units.

Most everyday characters fit into a single code unit.

"A".length
// 1

"B".length
// 1

"7".length
// 1

But many emojis are too large to fit into just one UTF-16 code unit.

So JavaScript stores them using two code units.

That's why this happens:

"😀".length

Output:

You still see one emoji.

But internally, JavaScript needs two UTF-16 code units to represent it.

So .length reports 2.

Wait... Does `length` Lie?

Not exactly.

It simply answers a different question.

Most beginners assume .length means:

"How many characters can I see?"

But JavaScript is actually answering:

"How many UTF-16 code units are stored?"

Those aren't always the same thing.

For everyday English text, they usually match.

For emojis and some less common Unicode characters, they don't.

That's why it's safer to think of .length as:

"The internal length of this JavaScript string."

rather than

"The number of visible characters."

This Doesn't Only Affect Emojis

Emojis are the easiest example because they're familiar.

But they're not the only ones.

Some languages contain characters that are formed by combining multiple Unicode values.

Some accented letters can also be represented in more than one way.

Even certain flags are actually made by combining two separate Unicode characters into what looks like a single symbol.

For example:

🇺🇸

looks like one flag.

Behind the scenes, it's actually composed of multiple Unicode code points.

This is why working with text across different languages can be surprisingly complex.

Fortunately, for most everyday applications, you don't need to worry about these details unless you're doing advanced text processing.

Still, it's useful to know that what humans see as one character isn't always what the computer stores as one unit.

Now That We Know How Text Is Stored...

Understanding encoding explains a lot of strange behavior.

But most of the time, we're not thinking about bytes or Unicode.

We're simply trying to answer practical questions like:

How do I remove extra spaces from user input?
How do I split a full name into first and last name?
How do I check whether a sentence contains a specific word?
How do I extract all the numbers from a block of text?

These are the kinds of operations you'll use almost every day.

Fortunately, programming languages give us a rich toolbox for working with strings.

The Everyday String Toolbox

Most of the time, we don't spend our day thinking about UTF-8, UTF-16, or immutable strings.

We're simply trying to work with text.

Maybe we're reading a user's name from a form.

Maybe we're processing a CSV file.

Maybe we're cleaning data before saving it to a database.

Fortunately, most programming languages provide a handful of string methods that you'll use over and over again.

To keep things simple, let's work with the same piece of text throughout this section.

const raw = "  Ada Lovelace, 1815-1852  ";

At first glance, it looks fine.

But if you look carefully, you'll notice two extra spaces at the beginning and two more at the end.

Small details like these are surprisingly common when dealing with user input.

Let's clean it up.

Step 1: Remove Unwanted Spaces

The first tool every programmer should know is trim().

const trimmed = raw.trim();

Now our string becomes:

Ada Lovelace, 1815-1852

The extra spaces are gone.

One important thing to remember is that trim() doesn't change the original string.

Remember what we learned earlier?

Strings are immutable.

So this:

raw.trim();

does absolutely nothing useful if you ignore the returned value.

You need to store the new string somewhere.

const trimmed = raw.trim();

This tiny habit saves beginners from a lot of confusion.

Why Is `trim()` So Important?

Imagine a login form.

A user accidentally types:

john@example.com␠

Notice the invisible space at the end.

To us, it looks exactly like:

john@example.com

But to the computer, they're different strings.

Without trimming the input, a perfectly valid email might fail to match what's stored in your database.

That's why one of the simplest best practices is:

Whenever text comes from a user, trim it before comparing or storing it.

It removes accidental spaces without changing the meaningful part of the text.

Step 2: Break Text Into Pieces

Now that our string is clean, we can separate it into smaller parts.

Right now, everything is stored in one string.

Ada Lovelace, 1815-1852

Suppose we want the name and the years separately.

This is exactly what split() is designed for.

const [name, years] = trimmed.split(", ");

Now we have two independent values.

name  → Ada Lovelace

years → 1815-1852

The text hasn't disappeared.

We've simply told JavaScript:

"Whenever you see ", ", cut the string into pieces."

This is useful for processing CSV files, parsing names, reading configuration files, and many other real-world tasks.

Step 3: Does This Text Contain Something?

Sometimes you don't need to split a string.

You just want to know whether a word exists inside it.

Suppose we have:

const sentence = "JavaScript is fun";

If we want to know whether the word "fun" appears, we can simply write:

sentence.includes("fun");

Result:

true

If the word isn't present,

sentence.includes("Python");

returns

false

It's simple, readable, and usually the best choice when you only need a yes-or-no answer.

What About `indexOf()`?

Before includes() became common, developers often used indexOf().

sentence.indexOf("fun");

Instead of returning true or false, it returns the position where the text starts.

For example:

If the text isn't found, it returns:

-1

Both methods are useful.

If you only care whether something exists, includes() is usually easier to read.

If you also need the position, indexOf() gives you that information.

Step 4: Extract Just the Part You Need

Sometimes you don't want the entire string.

You only need a small section of it.

That's where slice() comes in.

Imagine this string:

const language = "JavaScript";

If we only want the first four letters:

language.slice(0, 4);

we get:

Java

The first number tells JavaScript where to start.

The second tells it where to stop.

The character at the stopping position isn't included.

You can think of slice() as cutting out a portion of the original string while leaving the original untouched.

Step 5: Build Better Strings

Sooner or later, you'll need to combine variables into a sentence.

Suppose we already have:

const name = "Ada Lovelace";
const years = "1815-1852";

An older way to build a sentence would be:

name + " lived from " + years

It works.

But once the sentence becomes longer, all those + operators start making the code harder to read.

Modern JavaScript gives us a cleaner alternative called template literals.

`${name} lived from ${years}`

The result is:

Ada Lovelace lived from 1815-1852

The variables fit naturally into the sentence, making the code much easier to write and understand.

Whenever you're building strings with variables, template literals are usually the preferred approach.

So Far, Everything Has Been Simple...

Every method we've seen works with exact pieces of text.

trim() removes spaces.

split() cuts text apart.

includes() searches for exact words.

slice() extracts a section.

Template literals build new strings.

But what happens when the text you're looking for isn't fixed?

Suppose you don't know the exact year.

You simply want to find every number inside a paragraph.

Or every email address.

Or every phone number.

Searching for exact words is no longer enough.

That's where one of the most powerful and sometimes intimidating tools in programming enters the picture:

Regular Expressions, or simply Regex.

When Simple Search Isn't Enough

So far, every string method we've used has worked with exact text.

For example:

sentence.includes("JavaScript");

JavaScript looks for the exact word "JavaScript".

That's great when you already know what you're searching for.

But real-world text is often much messier.

Imagine someone gives you this string:

Ada Lovelace, 1815-1852

You don't care about the name.

You don't even care about the hyphen.

You simply want every number that appears in the text.

Or imagine you're processing thousands of user comments and want to find:

every email address
every phone number
every URL
every date

You can't possibly search for every number or every email one by one.

You need a way to describe a pattern instead of an exact word.

That's exactly why Regular Expressions, commonly called Regex, exist.

Think of Regex as a Search Rule

Instead of saying,

"Find the word JavaScript."

Regex lets you say,

"Find anything that looks like a number."

"Find anything that looks like an email address."

"Find every word that starts with a capital letter."

In other words, regex doesn't search for one specific piece of text.

It searches for a pattern.

That's what makes it so powerful.

A Simple Example

Let's go back to our string:

const years = "1815-1852";

Suppose we want to know whether this string contains any digits.

We can write:

/\d+/.test(years);

The result is:

true

Let's break down the pattern.

\d

means:

Match any digit from 0 to 9.

The + means:

Match one or more of them.

So together,

\d+

means:

Find one or more consecutive digits.

That's enough to match:

and

without us ever typing those numbers explicitly.

Extracting Every Match

Sometimes we don't just want to know whether a match exists.

We want the actual matches.

That's where match() comes in.

const allYears = years.match(/\d+/g);

The result is:

["1815", "1852"]

The pattern is exactly the same.

The only new thing is the g flag.

You can think of g as meaning:

"Don't stop after the first match. Keep searching until you've found them all."

Without it, JavaScript would stop after finding "1815".

With it, it continues and also finds "1852".

Regex Is Powerful...

By now, you can probably see why developers love regex.

With the right pattern, you can search through huge amounts of text and find exactly what you're looking for.

Need every number?

Regex.

Every hashtag?

Regex.

Every date?

Regex.

Every email?

Regex.

It's an incredibly versatile tool.

...But It's Also Easy to Misuse

Regex has a reputation. Not because it's bad. But because it's very easy to make it more complicated than it needs to be.

Many beginners have this experience:

They find a regex online. It seems to work. So they copy it into their project.

A month later, they look at the same line of code and think:

"I have absolutely no idea what this does."

The problem gets even worse if the regex has no comments explaining it.

A mysterious regex is like a complicated math formula with no explanation. It might be correct. But nobody wants to touch it. Including the person who originally wrote it.

Real-World Regex Is Harder Than It Looks

Take email validation as an example.

At first, it sounds easy.

Just check whether the text contains:

Right?

Unfortunately, real email addresses are much more complicated.

Some contain +.

Some contain subdomains.

Some use international characters.

Some perfectly valid email addresses look surprisingly unusual.

Writing a regex that correctly accepts every valid email while rejecting every invalid one is much harder than it first appears.

That's why many developers prefer using well-tested libraries instead of writing complex validation regex from scratch.

Another Hidden Problem

Regex can also affect performance.

Some poorly written patterns force the computer to try an enormous number of possible matches before finally giving up.

This problem is known as catastrophic backtracking.

You don't need to understand the details yet.

Just remember this rule:

A shorter, simpler regex is usually better than a clever one that nobody understands.

Best Practices

At this point, we've covered the most important ideas about working with strings.

Here are two habits that will save you from many common bugs.

1. Trim User Input

Whenever text comes from a user, remove unnecessary spaces before using it.

const email = input.trim();

This small step helps prevent failed comparisons, incorrect lookups, and frustrating bugs caused by invisible whitespace.

2. Avoid Repeated String Concatenation in Large Loops

For small pieces of text, using += is perfectly fine.

But when building very large strings inside loops, it's more efficient to collect the pieces first and join them once.

const parts = [];

for (const word of words) {
    parts.push(word);
}

const result = parts.join("");

It's a simple change that scales much better as your program grows.

Common Beginner Mistakes

Let's finish by revisiting a few misconceptions that often catch new programmers off guard.

Mistake #1: Assuming `length` Means "Visible Characters"

For plain English text, that's usually true.

But once emojis or certain Unicode characters appear, it isn't.

"😀".length

returns:

because JavaScript counts UTF-16 code units, not the number of characters your eyes see.

Mistake #2: Forgetting That Strings Are Immutable

Methods like:

trim()
replace()
toUpperCase()

don't modify the existing string.

They return a new one.

If you ignore that returned value, nothing changes.

Mistake #3: Writing Regex Nobody Can Read

Regex is one of the most powerful tools in text processing.

It's also one of the easiest places to create confusing code.

If a regex becomes long or difficult to understand, add a comment explaining what it's supposed to match or consider whether there's a simpler approach.

Your future self (and your teammates) will thank you.

Wrapping Up

Strings seem simple because we use text every day.

But programming treats text very differently than humans do.

A string isn't just a sequence of letters. It's an immutable piece of data stored using an encoding, manipulated through specialized tools, and sometimes searched using powerful patterns.

Once you understand these ideas, many "weird" behaviors start making sense:

Why toUpperCase() doesn't change the original string.
Why one emoji can have a length of 2.
Why trimming user input prevents subtle bugs.
Why regex searches for patterns, not exact words.
Why repeatedly using += isn't always the best choice.

The next time you work with text, you'll know there's much more happening behind the scenes than meets the eye and you'll have the tools to handle it with confidence.

Compilation vs. Interpretation: The Question That Turned Out to Be More Complicated Than Expected

Shajibul Alam Shihab — Tue, 14 Jul 2026 06:58:17 +0000

Compilation vs. Interpretation: The Question That Turned Out to Be More Complicated Than Expected

For a long time, the answer seemed obvious.

"Is JavaScript compiled or interpreted?"

The response came almost automatically:

"Interpreted."

Then another question appeared.

"If JavaScript is interpreted, why does V8 have a compiler?"

That single question unraveled a misconception that many developers including experienced ones carry for years.

The truth is that modern programming languages rarely fit into neat labels like compiled or interpreted. Once the execution pipeline is understood, those labels start to feel overly simplistic.

Every program begins life as source code.

Whether it's JavaScript, Python, Rust, Go, or TypeScript, none of that code can be executed directly by a processor.

A CPU understands only one thing:

Machine code.

Somewhere between writing code and seeing a program run, translation has to happen.

The only real difference between languages is when and how that translation takes place.

The First Approach: Translate Everything Up Front

Imagine translating an entire novel before anyone starts reading it.

The work takes time initially, but once it's finished, every future read is fast because no translation is needed anymore.

That's exactly how Ahead-of-Time (AOT) compilation works.

Languages like C, Rust, and Go compile the entire program into native machine code before execution begins.

gcc program.c -o program
./program

By the time ./program runs, every instruction has already been translated into machine code.

The CPU simply executes it.

The advantages are obvious:

Excellent runtime performance
Errors are caught before execution
No translation overhead while the program is running

The trade-off?

A separate executable is needed for every target platform and architecture.

The Second Approach: Translate While Running

Now imagine a translator sitting beside the reader.

Instead of translating the whole book beforehand, each sentence is translated only when it's reached.

No preparation.

No finished translated copy.

Just translation and execution happening together.

That's the traditional idea of interpretation.

A command like:

python script.py

doesn't produce a standalone executable first.

Instead, the interpreter reads the program and executes it as it goes.

This approach offers incredible portability.

The same source code works anywhere the interpreter exists.

The downside is that translation work happens every time the program runs.

Then Came the Plot Twist

For years, programming books often divided languages into two categories:

Compiled
Interpreted

That classification made sense decades ago.

Today?

Not so much.

Modern language runtimes are far more sophisticated.

Instead of choosing one approach, many combine several.

Enter Bytecode

Before reaching machine code, many languages first compile into something called bytecode.

Bytecode isn't machine code.

It's an intermediate instruction set designed to be portable across different operating systems and processors.

Instead of looking like this:

Source Code
      ↓
Machine Code

the pipeline becomes:

Source Code
      ↓
Bytecode
      ↓
Virtual Machine
      ↓
Execution

This is the first clue that the old "compiled vs interpreted" debate isn't telling the whole story.

Python does this.

Java does this.

Even though both are commonly described as interpreted languages, they still perform a compilation step.

It just doesn't produce machine code directly.

And Then Things Get Even More Interesting

Modern runtimes don't stop at bytecode.

They watch how a program behaves while it's running.

Suppose a function gets called once.

Nothing special happens.

Suppose another function gets called a million times inside a loop.

Now the runtime notices.

Instead of interpreting that same code forever, it decides something.

"This function is important."

That frequently executed section—often called a hot path—gets compiled into native machine code while the program is still running.

This process is called Just-In-Time (JIT) compilation.

It's one of the reasons modern JavaScript engines are incredibly fast.

Rather than compiling everything upfront or interpreting everything forever, they optimize only the code that actually matters.

The result is a balance between fast startup and excellent long-running performance.

JavaScript's V8, Java's HotSpot JVM, and PyPy all use this strategy.

So... What About TypeScript?

This was the part that completely changed the mental model.

At first glance, TypeScript seems similar to C.

After all, there's a compiler.

Running tsc certainly feels like compilation.

But tsc isn't producing machine code.

Its job is much simpler.

Given this code:

function double(n: number): number {
    return n * 2;
}

The TypeScript compiler checks the types...

removes every type annotation...

and emits plain JavaScript.

function double(n) {
    return n * 2;
}

That's where tsc stops.

The resulting JavaScript is then handed to a JavaScript engine like V8.

Only then does the familiar execution pipeline begin:

Parse JavaScript
Generate bytecode
Start execution
Identify hot paths
JIT compile them into native machine code

In other words, a TypeScript program goes through two completely different compilation stages.

First:

TypeScript → JavaScript

Later:

JavaScript → Native Machine Code (via V8's JIT compiler)

That's why answering

"Is TypeScript compiled or interpreted?"

with a single word doesn't really work.

It's both.

Just at different stages.

The Biggest Misconceptions

One misconception appears almost everywhere:

"Interpreted languages aren't compiled."

Modern Python and Java both compile into bytecode before execution.

Compilation still exists.

It simply happens at a different stage.

Another common misconception:

"tsc works like the C compiler."

It doesn't.

The TypeScript compiler never produces machine code.

It only performs type checking and transpiles TypeScript into JavaScript.

The JavaScript engine still carries the responsibility of producing executable machine instructions.

One Last Thing About Performance

Benchmarks for JIT-powered languages can be surprisingly misleading.

The first few executions often represent the runtime before optimization.

Only after the runtime identifies hot paths and compiles them into native machine code does peak performance begin to appear.

That's why serious benchmarks usually include a warm-up phase before measuring execution speed.

Perhaps the biggest lesson wasn't learning what compilation or interpretation means.

It was realizing that the question itself has become outdated.

Modern programming languages aren't strictly compiled.

They aren't strictly interpreted either.

Most combine multiple techniques compilation, bytecode, interpretation, and JIT optimization to balance portability, startup time, developer experience, and runtime performance.

So the next time the question appears

"Is JavaScript compiled or interpreted?"

The most accurate answer might simply be:

"It's more interesting than that."

Python for Beginners: Installation, Basics, Logic, Files & Mini Project

Shajibul Alam Shihab — Tue, 17 Feb 2026 12:30:30 +0000

Python Foundations & Workflow

Installing Python

Windows:

# Download from python.org
# Or use winget
winget install Python.Python.3.11

পাইথন ইনস্টল করার পর টার্মিনালে python --version লিখে চেক করুন যে সঠিকভাবে ইনস্টল হয়েছে কিনা।

Python Data Types & Variables

Basic Data Types / মৌলিক ডেটা টাইপ

Integer: যেকোনো পূর্ণ সংখ্যা (১, ২, ১০০, -৫)
Float: দশমিক সংখ্যা (৩.১৪, ৫.৯)
String: টেক্সট বা লেখা ("নাম", "Hello")
Boolean: শুধু দুটি মান থাকতে পারে - True অথবা False

# Integer (পূর্ণসংখ্যা)
age = 25
print(type(age))  # <class 'int'>

# Float (দশমিক সংখ্যা)
height = 5.9
print(type(height))  # <class 'float'>

# String (স্ট্রিং/টেক্সট)
name = "আহমেদ"  # Bengali text supported
print(type(name))  # <class 'str'>

# Boolean (সত্য/মিথ্যা)
is_student = True
print(type(is_student))  # <class 'bool'>

# None (কিছুই নেই)
result = None
print(type(result))  # <class 'NoneType'>

Lists & Dictionaries (Important for ML)

Lists / লিস্ট

লিস্ট হলো একাধিক ডেটা একসাথে রাখার উপায়
লিস্টের ইনডেক্স শূন্য (০) থেকে শুরু হয়
নেগেটিভ ইনডেক্স (-1) দিয়ে শেষ থেকে অ্যাক্সেস করা যায়

# Creating lists (লিস্ট তৈরি)
numbers = [1, 2, 3, 4, 5]
names = ["রহিম", "করিম", "সালমা"]
mixed = [1, "hello", 3.14, True]

# Accessing elements (এলিমেন্ট অ্যাক্সেস)
print(numbers[0])  # 1 (প্রথম এলিমেন্ট)
print(numbers[-1])  # 5 (শেষ এলিমেন্ট)

# Slicing (স্লাইসিং)
print(numbers[1:4])  # [2, 3, 4]
print(numbers[:3])   # [1, 2, 3] (প্রথম তিনটি)
print(numbers[2:])   # [3, 4, 5] (তৃতীয় থেকে শেষ পর্যন্ত)

# List operations
numbers.append(6)        # শেষে যোগ করা
numbers.insert(0, 0)     # নির্দিষ্ট স্থানে যোগ করা
numbers.remove(3)        # নির্দিষ্ট মান মুছে ফেলা
numbers.pop()            # শেষ এলিমেন্ট মুছে ফেলা

# List comprehension (খুবই শক্তিশালী!)
squares = [x**2 for x in range(10)]
# [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

even_squares = [x**2 for x in range(10) if x % 2 == 0]
# [0, 4, 16, 36, 64]

Dictionaries / ডিকশনারি

ডিকশনারি হলো key-value পেয়ার
প্রতিটি key এর বিপরীতে একটি value থাকে
key দিয়ে খুব দ্রুত value খুঁজে পাওয়া যায়

# Creating dictionary (ডিকশনারি তৈরি)
student = {
    "name": "আহমেদ",
    "age": 22,
    "cgpa": 3.85,
    "subjects": ["Math", "Physics", "CS"]
}

# Accessing values (মান অ্যাক্সেস)
print(student["name"])        # আহমেদ
print(student.get("age"))     # 22

# Adding/Updating (যোগ/আপডেট করা)
student["email"] = "ahmed@example.com"
student["age"] = 23

# Dictionary methods
keys = student.keys()         # সব key পাওয়া
values = student.values()     # সব value পাওয়া
items = student.items()       # (key, value) pairs

# Dictionary comprehension
squared_dict = {x: x**2 for x in range(5)}
# {0: 0, 1: 1, 2: 4, 3: 9, 4: 16}

Control Flow (if/else, loops)

If-Else Statements

if-else দিয়ে শর্ত চেক করা যায় এবং সেই অনুযায়ী কোড চালানো যায়।

# Simple if-else
age = 20

if age >= 18:
    print("আপনি প্রাপ্তবয়স্ক")  # You are adult
else:
    print("আপনি নাবালক")      # You are minor

# Multiple conditions
marks = 85

if marks >= 90:
    grade = "A+"
elif marks >= 80:
    grade = "A"
elif marks >= 70:
    grade = "B"
else:
    grade = "C"

print(f"Your grade: {grade}")

# Ternary operator (এক লাইনে if-else)
status = "Pass" if marks >= 50 else "Fail"

for loop: নির্দিষ্ট সংখ্যকবার বা লিস্টের প্রতিটি আইটেমের জন্য চলে
while loop: যতক্ষণ শর্ত সত্য ততক্ষণ চলতে থাকে
break: লুপ থামিয়ে দেয়
continue: বর্তমান ইটারেশন স্কিপ করে পরেরটিতে যায়

For Loops / ফর লুপ

# Basic for loop
for i in range(5):
    print(i)  # 0, 1, 2, 3, 4

# Loop through list
fruits = ["আম", "কলা", "জাম"]
for fruit in fruits:
    print(fruit)

# Loop with index and value
for index, fruit in enumerate(fruits):
    print(f"{index}: {fruit}")

# Range with start, stop, step
for i in range(0, 10, 2):  # 0, 2, 4, 6, 8
    print(i)

While Loops / হোয়াইল লুপ

# Basic while loop
count = 0
while count < 5:
    print(count)
    count += 1

# Break and continue
for i in range(10):
    if i == 3:
        continue  # Skip 3
    if i == 7:
        break     # Stop at 7
    print(i)

Functions / ফাংশন

Defining Functions

ফাংশন হলো পুনরায় ব্যবহারযোগ্য কোড ব্লক
def দিয়ে ফাংশন তৈরি করা হয়
return দিয়ে ফাংশন থেকে মান ফেরত পাঠানো হয়
*args: যেকোনো সংখ্যক আর্গুমেন্ট নেয়
**kwargs: যেকোনো সংখ্যক keyword আর্গুমেন্ট নেয়

# Basic function
def greet(name):
    """এই ফাংশন একটি নাম নিয়ে শুভেচ্ছা বার্তা দেয়"""
    return f"Hello, {name}!"

message = greet("আহমেদ")
print(message)  # Hello, আহমেদ!

# Multiple parameters
def add(a, b):
    """দুটি সংখ্যা যোগ করে"""
    return a + b

result = add(5, 3)
print(result)  # 8

# Default arguments
def power(base, exponent=2):
    """একটি সংখ্যার ঘাত বের করে (ডিফল্ট ঘাত = ২)"""
    return base ** exponent

print(power(3))      # 9 (3^2)
print(power(3, 3))   # 27 (3^3)

# *args - variable number of arguments
def sum_all(*numbers):
    """যেকোনো সংখ্যক সংখ্যা যোগ করে"""
    total = 0
    for num in numbers:
        total += num
    return total

print(sum_all(1, 2, 3))        # 6
print(sum_all(1, 2, 3, 4, 5))  # 15

# **kwargs - keyword arguments
def student_info(**info):
    """Student information প্রিন্ট করে"""
    for key, value in info.items():
        print(f"{key}: {value}")

student_info(name="রহিম", age=22, cgpa=3.7)

Lambda Functions (Anonymous Functions)

# Regular function
def square(x):
    return x ** 2

# Lambda equivalent (এক লাইনে)
square_lambda = lambda x: x ** 2

print(square(5))         # 25
print(square_lambda(5))  # 25

# Lambda with multiple arguments
add = lambda a, b: a + b
print(add(3, 5))  # 8

# Used with map, filter
numbers = [1, 2, 3, 4, 5]
squared = list(map(lambda x: x**2, numbers))
# [1, 4, 9, 16, 25]

even = list(filter(lambda x: x % 2 == 0, numbers))
# [2, 4]

File Handling (CSV read/write, Pathlib)

with open() ব্যবহার করলে ফাইল অটোমেটিক বন্ধ হয়ে যায়
'r' = read (পড়া), 'w' = write (লেখা), 'a' = append (যোগ করা)
encoding='utf-8' বাংলা টেক্সটের জন্য জরুরি
Pathlib আধুনিক এবং ক্রস-প্ল্যাটফর্ম উপায়

Reading Files / ফাইল পড়া

# Basic file reading
with open('data.txt', 'r', encoding='utf-8') as file:
    content = file.read()
    print(content)

# Read line by line
with open('data.txt', 'r', encoding='utf-8') as file:
    for line in file:
        print(line.strip())  # strip() removes \n

# Read all lines into a list
with open('data.txt', 'r', encoding='utf-8') as file:
    lines = file.readlines()

Writing Files / ফাইলে লেখা

# Write mode (overwrites existing file)
with open('output.txt', 'w', encoding='utf-8') as file:
    file.write("Hello, World!\n")
    file.write("নমস্কার, পৃথিবী!\n")

# Append mode (adds to existing file)
with open('output.txt', 'a', encoding='utf-8') as file:
    file.write("New line added\n")

Working with CSV Files

import csv

# Reading CSV
with open('students.csv', 'r', encoding='utf-8') as file:
    csv_reader = csv.reader(file)

    # Skip header
    next(csv_reader)

    for row in csv_reader:
        name, age, cgpa = row
        print(f"{name}: {cgpa}")

# Writing CSV
students = [
    ["Name", "Age", "CGPA"],
    ["আহমেদ", 22, 3.85],
    ["রহিম", 21, 3.70],
    ["সালমা", 23, 3.92]
]

with open('students.csv', 'w', encoding='utf-8', newline='') as file:
    csv_writer = csv.writer(file)
    csv_writer.writerows(students)

# Using DictReader/DictWriter (recommended)
with open('students.csv', 'r', encoding='utf-8') as file:
    csv_reader = csv.DictReader(file)
    for row in csv_reader:
        print(row['Name'], row['CGPA'])

Using Pathlib (Modern approach)

from pathlib import Path

# Create Path object
data_dir = Path('data')
file_path = data_dir / 'students.csv'

# Check if exists
if file_path.exists():
    print("File exists")

# Create directory
data_dir.mkdir(exist_ok=True)

# Read file
content = file_path.read_text(encoding='utf-8')

# Write file
file_path.write_text("New content", encoding='utf-8')

# Get file info
print(file_path.name)       # students.csv
print(file_path.stem)       # students
print(file_path.suffix)     # .csv
print(file_path.parent)     # data

8. Exception Handling / এক্সেপশন হ্যান্ডলিং

try: যে কোড এরর দিতে পারে তা এখানে রাখি
except: এরর হলে এই কোড চলবে
finally: এরর হোক বা না হোক এই কোড চলবে
raise: নিজে এরর তৈরি করা

# Basic try-except
try:
    number = int(input("Enter a number: "))
    result = 10 / number
    print(f"Result: {result}")
except ValueError:
    print("দয়া করে একটি সংখ্যা লিখুন!")
except ZeroDivisionError:
    print("শূন্য দিয়ে ভাগ করা যায় না!")

# Multiple exceptions
try:
    file = open('data.txt', 'r')
    content = file.read()
    value = int(content)
except (FileNotFoundError, ValueError) as e:
    print(f"Error occurred: {e}")
finally:
    file.close()  # Always executes

# Raising exceptions
def calculate_percentage(marks, total):
    if total == 0:
        raise ValueError("Total cannot be zero")
    return (marks / total) * 100

try:
    percentage = calculate_percentage(85, 0)
except ValueError as e:
    print(f"Error: {e}")

Logging Basics (Debugging Setup)

লগিং ব্যবহার করে প্রোগ্রামের কি হচ্ছে তা ট্র্যাক করা যায়, যা ডিবাগিংয়ে খুব সাহায্য করে।

import logging

# Basic logging
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s - %(levelname)s - %(message)s'
)

logging.debug("এটি একটি debug message")
logging.info("এটি একটি info message")
logging.warning("এটি একটি warning message")
logging.error("এটি একটি error message")
logging.critical("এটি একটি critical message")

# Logging to file
logging.basicConfig(
    filename='app.log',
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s'
)

logging.info("Application started")

Mini-Project: CSV Data Cleaner

import csv
from pathlib import Path

def clean_csv(input_file, output_file):
    """
    CSV file থেকে empty rows এবং duplicate rows মুছে ফেলে

    Args:
        input_file: Input CSV file path
        output_file: Output CSV file path
    """
    # Read data
    with open(input_file, 'r', encoding='utf-8') as file:
        reader = csv.DictReader(file)
        rows = list(reader)

    # Remove empty rows
    cleaned_rows = [row for row in rows if any(row.values())]

    # Remove duplicates
    seen = set()
    unique_rows = []
    for row in cleaned_rows:
        row_tuple = tuple(row.items())
        if row_tuple not in seen:
            seen.add(row_tuple)
            unique_rows.append(row)

    # Write cleaned data
    if unique_rows:
        with open(output_file, 'w', encoding='utf-8', newline='') as file:
            writer = csv.DictWriter(file, fieldnames=unique_rows[0].keys())
            writer.writeheader()
            writer.writerows(unique_rows)

        print(f"✓ Cleaned {len(rows)} rows → {len(unique_rows)} unique rows")
        print(f"✓ Saved to {output_file}")

# Usage
clean_csv('dirty_data.csv', 'clean_data.csv')

Key Takeaways

✓ Python এর মৌলিক syntax এবং data types
✓ List, Dictionary ব্যবহার করে data organize করা
✓ Control flow দিয়ে logic তৈরি করা
✓ Function লিখে reusable code তৈরি করা
✓ File handling দিয়ে data read/write করা
✓ Exception handling দিয়ে error handle করা

Javascript ES6 (ECMAScript 2015) Features

Shajibul Alam Shihab — Thu, 30 Jan 2025 11:15:32 +0000

ES6 also known as ECMAScript 2015 is a major update to JavaScript, and it introduced many new features that make JavaScript more powerful and easier to work with. Whether you're a beginner or an experienced developer, understanding ES6 is essential for modern web development.

In this blog, we'll cover all the key features of ES6, including let and const, arrow functions, template literals, destructuring, spread and rest operators, classes, modules, and much more.

So, let's get started!

1. let and const

ES6 introduced two new ways to declare variables: let and const. Before ES6, we only had var, but var has some issues, especially with scope. Let's see how let and const solve these problems.

let is used for variables that can change their value, while const is used for variables that cannot be reassigned. Here's an example:

let name = "John";
name = "Doe"; // This is allowed

const age = 25;
age = 30; // This will throw an error

The main difference between let and var is block scope. Variables declared with let are only accessible within the block they are defined in, while var is function-scoped. For example:

if (true) {
  let x = 10;
  var y = 20;
}
console.log(x); // Error: x is not defined
console.log(y); // 20

So, always use let and const instead of var in modern JavaScript.

2. Arrow Functions

Next, let's talk about arrow functions. Arrow functions are a shorter and more concise way to write functions in JavaScript. They also handle the this keyword differently.

Here's a comparison between a regular function and an arrow function:

// Regular function
function add(a, b) {
  return a + b;
}

// Arrow function
const add = (a, b) => a + b;

Arrow functions are especially useful for callback functions. For example:

const numbers = [1, 2, 3];
const doubled = numbers.map((num) => num * 2);

One important thing to note is that arrow functions do not have their own this. Instead, they inherit this from the surrounding context. This makes them ideal for use in methods like setTimeout or event listeners.

3. Template Literals

ES6 introduced template literals, which make it easier to work with strings. Instead of using single or double quotes, we use backticks (`). Template literals allow us to embed expressions inside strings using ${}.

Here's an example:

const name = "John";
const age = 25;
const message = `My name is ${name} and I am ${age} years old.`;
console.log(message); // My name is John and I am 25 years old.

Template literals also support multi-line strings without needing to use \n:

const html = `
  <div>
    <h1>Hello, World!</h1>
  </div>
`;

This makes our code much cleaner and easier to read."

4. Destructuring

Destructuring is a powerful feature in ES6 that allows us to extract values from arrays or objects into variables. Let's start with array destructuring:

const numbers = [1, 2, 3];
const [a, b, c] = numbers;
console.log(a); // 1
console.log(b); // 2
console.log(c); // 3

We can also use destructuring with objects:

const person = { name: "John", age: 25 };
const { name, age } = person;
console.log(name); // John
console.log(age); // 25

Destructuring is very useful when working with functions that return multiple values or when dealing with complex data structures.

5. Spread and Rest Operators

The spread operator (...) allows us to expand an array or object into individual elements. For example:

const numbers = [1, 2, 3];
const newNumbers = [...numbers, 4, 5];
console.log(newNumbers); // [1, 2, 3, 4, 5]

We can also use the spread operator to copy objects:

const person = { name: "John", age: 25 };
const newPerson = { ...person, city: "Dhaka" };
console.log(newPerson); // { name: "John", age: 25, city: "Dhaka" }

The rest operator is used to collect multiple elements into an array. It's often used in function parameters:

function sum(...numbers) {
  return numbers.reduce((total, num) => total + num, 0);
}
console.log(sum(1, 2, 3)); // 6

These operators are very versatile and can simplify many tasks in JavaScript.

6. Classes

ES6 introduced classes, which provide a cleaner and more structured way to work with objects and inheritance. Here's an example of a class:

class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  greet() {
    console.log(`Hello, my name is ${this.name}`);
  }
}

const john = new Person("John", 25);
john.greet(); // Hello, my name is John

We can also use inheritance with the extends keyword:

class Student extends Person {
  constructor(name, age, grade) {
    super(name, age);
    this.grade = grade;
  }

  study() {
    console.log(`${this.name} is studying`);
  }
}

const alice = new Student("Alice", 20, "A");
alice.greet(); // Hello, my name is Alice
alice.study(); // Alice is studying

Classes make it easier to organize and reuse code in JavaScript.

7. Modules

ES6 introduced a native module system for JavaScript. With modules, we can split our code into multiple files and import/export functionality as needed.

Here's an example of exporting and importing:

// math.js
export const add = (a, b) => a + b;
export const subtract = (a, b) => a - b;

// main.js
import { add, subtract } from './math.js';
console.log(add(2, 3)); // 5
console.log(subtract(5, 2)); // 3

We can also use default exports:

// math.js
export default function multiply(a, b) {
  return a * b;
}

// main.js
import multiply from './math.js';
console.log(multiply(2, 3)); // 6

Modules help us keep our code organized and maintainable.

8. Promises and Async/Await

ES6 introduced Promises to handle asynchronous operations in a more elegant way. A Promise represents a value that may be available now, in the future, or never.

Here's an example of a Promise:

const fetchData = () => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve("Data fetched!");
    }, 2000);
  });
};

fetchData().then((data) => console.log(data)); // Data fetched!

ES7 introduced async/await, which makes working with Promises even easier:

const fetchData = async () => {
  const data = await fetchData();
  console.log(data); // Data fetched!
};

Async/await allows us to write asynchronous code that looks like synchronous code, making it easier to read and debug.

We've covered all the major features of ES6, including let and const, arrow functions, template literals, destructuring, spread and rest operators, classes, modules, and Promises and async/await. These features make JavaScript more powerful and easier to work with, and they are essential for modern web development.

This post was created using AI. But the planning, presentation and final editing of each piece is the result of my own efforts.

Thank you

Why Use Redux in React? Complete Guide in Bangla

Shajibul Alam Shihab — Sun, 12 Jan 2025 09:15:36 +0000

React ব্যবহার করার সময় কি কখনো আপনাদের মনে হয়েছে, "এই কম্পোনেন্ট থেকে ঐ কম্পোনেন্টে ডেটা পাঠানো এত জটিল কেন?" বা, "State ম্যানেজমেন্ট এর জন্য আরও ভালো উপায় কি হতে পারে?

আমরা জানি, React আমাদের কম্পোনেন্টগুলোর মধ্যে state শেয়ার করার জন্য খুবই কার্যকর। কিন্তু যখন অ্যাপ্লিকেশন বড় হতে থাকে, তখন এই state ম্যানেজমেন্ট এতটা জটিল হয়ে যায় যে কোড পড়া এবং মেইনটেন করা যেন একটা দুঃস্বপ্ন হয়ে দাঁড়ায়। এই সমস্যাগুলো সমাধানের জন্য Redux এসেছে। Redux এমন একটি লাইব্রেরি যা আমাদের state ম্যানেজমেন্টকে আরও সহজ এবং কার্যকর করে তোলে। এই পোস্টে আমরা খুব গভীরভাবে Redux-এর প্রতিটি দিক আলোচনা করবো।

আসুন, আমরা একবার ভাবি একটি React অ্যাপ্লিকেশন তৈরি করেছি যেখানে ডেটা Parent Component থেকে Child Component হয়ে আরও অনেক Nested Component পর্যন্ত যেতে হবে। এখন প্রতিটি লেভেলে ডেটা পাঠানোর জন্য props ব্যবহার করতে হচ্ছে। প্রথমে এটা সহজ মনে হলেও, অ্যাপ বড় হতে থাকলে এটা খুব জটিল হয়ে যায়। এই সমস্যার নাম হলো Props Drilling।

ধরি, আমাদের App কম্পোনেন্টের কাছে একটি state আছে, এবং সেই state আমরা AddToCartButton কম্পোনেন্টে পাঠাতে চাই। কিন্তু সমস্যা হলো, MainContent, ProductList আর Proeduct কম্পোনেন্টের মধ্য দিয়ে সেই state পাঠানো ছাড়া অন্য কোনো উপায় নেই। ফলে, এমন অনেক props ডেটা মাঝের কম্পোনেন্টে পৌঁছে যায় যেগুলো তাদের দরকারই নেই।

Props Drilling এর সমস্যা গুলো হলোঃ

কোড জটিল হয়ে যায়।
মাঝের কম্পোনেন্টগুলো অপ্রয়োজনীয় ডেটা বহন করে।
ডেটা শেয়ারিং ত্রুটিপূর্ণ এবং সময়সাপেক্ষ হয়।

React আমাদের জন্য Context API নামের একটি সমাধান এনেছে, যা Props Drilling সমস্যা অনেকটা সমাধান করতে পারে। Context API ব্যবহার করলে আমরা ডেটা সরাসরি প্রয়োজনীয় কম্পোনেন্টে পাঠাতে পারি, মাঝের কম্পোনেন্টগুলো এড়িয়ে। এটি নিঃসন্দেহে একটি ভালো সমাধান। তবে বড় অ্যাপ্লিকেশনের ক্ষেত্রে Context API এর কিছু সীমাবদ্ধতা রয়েছে।

Problems with Context API

Performance Issues: যখন Context এর state পরিবর্তিত হয়, তখন সেই Context এর নিচের সব কম্পোনেন্ট একসাথে re-render হয়। ফলে বড় অ্যাপ্লিকেশনে পারফরমেন্স সমস্যা দেখা দেয়।
Nested Providers: Context API এর Nested Providers ব্যবহার করলে কোড জটিল হয়ে যায়। একাধিক Context ব্যবহার করার ফলে Provider এর ভেতরে Provider থাকে, যাকে Provider Hell বলা হয়।
Scalability Issues: Context API ছোট বা মাঝারি অ্যাপ্লিকেশনের জন্য ভালো, কিন্তু বড় এবং জটিল অ্যাপ্লিকেশনের state ম্যানেজমেন্টের জন্য এটি পর্যাপ্ত নয়।"

তাহলে, Context API এর এই সীমাবদ্ধতাগুলো ছাড়িয়ে যাওয়ার জন্য আমাদের প্রয়োজন Redux। Redux আমাদের state ম্যানেজমেন্ট আরও সহজ এবং কার্যকর করতে সাহায্য করে। আসুন, এখন আমরা Redux কীভাবে কাজ করে এবং এটি কীভাবে আমাদের state ম্যানেজমেন্ট সহজ করে তোলে, তা নিয়ে আলোচনা করি।

Redux কী? এটি একটি প্রশ্ন যা অনেকের মনে আসে, বিশেষ করে যারা React-এ নতুন। Redux হলো এমন একটি লাইব্রেরি, যা JavaScript অ্যাপ্লিকেশনের জন্য state ম্যানেজমেন্ট সহজ করে। কিন্তু প্রশ্ন হলো কেন আমরা Redux ব্যবহার করবো? Redux কীভাবে কাজ করে? চলুন এই প্রশ্নগুলোর উত্তর খুঁজি।

Redux হলো একটি predictable state container। এর মানে হলো, এটি আমাদের অ্যাপ্লিকেশনের state বা data কে একটি নির্দিষ্ট নিয়ম মেনে এক জায়গায় সংরক্ষণ করে। ফলে state পরিবর্তন কোথায়, কখন এবং কীভাবে হচ্ছে, তা সহজেই বোঝা যায়।

Redux এর সবচেয়ে বড় সুবিধা হলো, এটি predictable। এর মানে, একবার state পরিবর্তনের নিয়ম (reducers) সেট করলে, state সবসময় নির্দিষ্ট নিয়মেই পরিবর্তিত হবে।

Redux ব্যবহারের কয়েকটি মূল কারণ হলো:

Centralized State Management: Redux আমাদের state এক জায়গায় সংরক্ষণ করতে দেয়। ফলে পুরো অ্যাপ্লিকেশনে ডেটা ম্যানেজ করা সহজ হয়।
Predictability: State কখন এবং কীভাবে পরিবর্তিত হচ্ছে, তা সবসময় একই নিয়ম মেনে চলে। এটি debug করা সহজ করে।
Time Travel Debugging: Redux DevTools ব্যবহার করে আমরা আমাদের state পরিবর্তনের ইতিহাস দেখতে এবং সেটা undo বা redo করতে পারি।

Redux কীভাবে কাজ করে, তা বোঝার জন্য আমাদের তিনটি গুরুত্বপূর্ণ জিনিস জানতে হবে Store, Action, এবং Reducer।

Store: Redux Store হলো সেই জায়গা যেখানে আমাদের অ্যাপ্লিকেশনের পুরো state সংরক্ষিত হয়। এটি হলো Redux এর মস্তিষ্ক। ধরি, একটি React অ্যাপ্লিকেশন আছে, যেখানে একটি counter state রাখতে হবে। এই state আমরা Store-এ সংরক্ষণ করবো, যাতে অ্যাপের যেকোনো জায়গা থেকে এটি ব্যবহার করা যায়।
Action: Action হলো এমন একটি জাভাস্ক্রিপ্ট অবজেক্ট, যা বলে দেয় অ্যাপ্লিকেশনে কী করতে হবে। Action হলো Redux এর মাধ্যমে state পরিবর্তনের প্রথম ধাপ।
Reducer: Reducer হলো একটি pure function, যা বলে দেয় Action এর ভিত্তিতে state কীভাবে পরিবর্তিত হবে। এটি আগের state এবং নতুন action নিয়ে কাজ করে এবং একটি নতুন state রিটার্ন করে।

Redux-এর কাজ করার পুরো প্রক্রিয়াটি একটি সাইকেলের মতো।

Dispatch an Action: কম্পোনেন্ট থেকে একটি Action পাঠানো হয়।
Reducer Processes the Action: Reducer Action অনুযায়ী state আপডেট করে।
Store Updates the State: Store নতুন state ধরে রাখে, যা কম্পোনেন্টে পৌঁছে যায়।

Redux শেখার এই পর্যায়ে আমরা বুঝেছি Redux কীভাবে কাজ করে। কিন্তু প্রশ্ন হলো Redux ব্যবহার করা কি সবসময় সহজ? সত্যি কথা বলতে, Vanilla Redux (Redux এর সাধারণ ব্যবহার) কখনো কখনো জটিল ও ক্লান্তিকর হয়ে যায়।

প্রথমে আমরা দেখবো Vanilla Redux ব্যবহারের কিছু সমস্যাঃ

Boilerplate Code: Redux এ অনেক boilerplate কোড লিখতে হয়। প্রতিটি action, reducer, এবং store সেটআপ করার জন্য প্রচুর সময় লাগে।
Complex Configuration: Store configure করতে middleware যোগ করা এবং enhancer সেট করা অনেক সময় জটিল হয়ে যায়।
Immutability Management: Reducer ফাংশন লেখার সময় state কে immutable রাখতে হবে। এটা নিশ্চিত করার জন্য অনেক manual কোড লিখতে হয়, যা নতুনদের জন্য ভীতিকর।
Debugging and Scaling Issues: Redux DevTools সাপোর্ট থাকলেও vanilla Redux-এ debugging এবং বড় অ্যাপ্লিকেশন ম্যানেজ করা কঠিন হয়ে যায়।

এই সব সমস্যার সমাধান নিয়ে এসেছে Redux Toolkit। এটি Redux ব্যবহারের জন্য একটি আধুনিক, সহজ এবং opinionated উপায়।

Redux Toolkit কী?

Redux Toolkit হলো Redux এর জন্য একটি অফিসিয়াল প্যাকেজ, যা আমাদের state ম্যানেজমেন্ট আরও সহজ ও কার্যকর করতে সাহায্য করে। এটি Redux এর সাধারণ কাজগুলোকে সহজ করে এবং boilerplate কোড কমায়।

কেন Redux Toolkit ব্যবহার করা উচিত?

Simpler Store Configuration: Redux Toolkit এর configureStore মেথড দিয়ে খুব সহজেই store configure করা যায়। Middleware এবং Redux DevTools সাপোর্ট অটোমেটিকভাবে এড করা থাকে।
Built-in createSlice: createSlice আমাদের action এবং reducer একসঙ্গে তৈরি করতে দেয়। ফলে কোড লেখার ঝামেলা কমে যায়।
Immutability with Immer: Redux Toolkit এর ভিতরে Immer নামে একটি লাইব্রেরি ব্যবহার করা হয়। এটি state কে immutable রাখতে সাহায্য করে। ফলে nested state পরিবর্তন করা সহজ হয়।
Redux DevTools and Middleware Integration: Redux Toolkit DevTools এবং middleware এর ইন্টিগ্রেশন অটোমেটিকভাবে দেয়, যা debugging সহজ করে।
Scalable and Maintainable: Redux Toolkit বড় অ্যাপ্লিকেশন ম্যানেজ করার জন্য আদর্শ। এটি কোড সহজে পড়া এবং মেইনটেইন করা সম্ভব করে।

Redux Toolkit Redux ব্যবহারের জন্য সহজ, আধুনিক এবং efficient উপায়। Vanilla Redux এর তুলনায় এটি দ্রুত, কম কোডে কাজ করে এবং বড় প্রজেক্ট পরিচালনার জন্য উপযুক্ত।

আমরা Redux এবং Redux Toolkit সম্পর্কে অনেক কিছু শিখেছি। কিন্তু এখন প্রশ্ন হলো React অ্যাপ্লিকেশনে Redux কীভাবে ব্যবহার করবো? এর জন্য আমাদের দরকার একটি ব্রিজ বা সংযোগ, যা React এবং Redux এর মধ্যে কাজ করবে। এই সংযোগের নাম হলো React-Redux।

React-Redux হলো একটি অফিসিয়াল লাইব্রেরি, যা React কম্পোনেন্ট এবং Redux store-এর মধ্যে যোগাযোগ স্থাপন করতে সাহায্য করে। এটি Redux এর state এবং actions কে React-এর সাথে ব্যবহার করার একটি সহজ এবং কার্যকর উপায়।

কেন আমরা React-Redux ব্যবহার করবো?

Simplifies State Access: Redux এর state এবং actions সরাসরি React কম্পোনেন্টে অ্যাক্সেস করা জটিল হতে পারে। React-Redux এটি সহজ করে।
Efficient Updates: React-Redux Redux state-এর পরিবর্তনের উপর ভিত্তি করে React কম্পোনেন্টগুলোকে efficient ভাবে আপডেট করে।
Built-in Best Practices: React-Redux অনেকগুলো built-in best practices ফলো করে। এটি আমাদের জন্য boilerplate কোড কমায় এবং performance উন্নত করে।

Core Concepts of React-Redux

Provider Component: React-Redux একটি Provider কম্পোনেন্ট প্রদান করে, যা Redux store কে পুরো React অ্যাপ্লিকেশনে access করতে দেয়।

import { Provider } from 'react-redux';
import store from './store';

const App = () => (
  <Provider store={store}>
    <MyComponent />
  </Provider>
);

Hooks for State and Dispatch: React-Redux ব্যবহার করার জন্য আমরা দুটি গুরুত্বপূর্ণ হুক ব্যবহার করি useSelector এবং useDispatch। - useSelector: Redux store থেকে state পড়ার জন্য। - useDispatch: Redux store-এ action পাঠানোর জন্য।

import { useSelector, useDispatch } from 'react-redux';
import { increment } from './counterSlice';

const Counter = () => {
  const count = useSelector((state) => state.counter.count);
  const dispatch = useDispatch();

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => dispatch(increment())}>Increment</button>
    </div>
  );
};

Optimized Re-renders: React-Redux এর হুক এবং connect মেথড state পরিবর্তনের সময় কম্পোনেন্টগুলোকে optimized ভাবে re-render করতে সাহায্য করে।

React-Redux React এবং Redux-এর মধ্যে একটি ব্রিজ তৈরি করে, যা ডেটা ম্যানেজমেন্টকে সহজ এবং কার্যকর করে। Provider, useSelector, এবং useDispatch এর মতো টুল ব্যবহার করে আমরা Redux এর state এবং actions React কম্পোনেন্টে আনতে পারি।

Redux এর বেসিক মেকানিজম আমরা শিখেছি। কিন্তু রিয়েল ওয়ার্ল্ড অ্যাপ্লিকেশনগুলোতে অনেক সময় আমাদের asynchronous ডেটা ফেচিং বা জটিল লজিক হ্যান্ডল করতে হয়। এখন আমরা Redux এর কিছু অ্যাডভান্সড টপিক, যেমন middleware, async actions, এবং debugging tools সম্পর্কে জানবো।

Middleware হলো Redux-এর জন্য একটি powerful tool, যা actions এবং reducers এর মধ্যে কাজ করে। এটি action dispatch হওয়ার পর এবং reducer পর্যন্ত পৌঁছানোর আগে এক্সিকিউট হয়।

Why Use Middleware?

Logging: Track actions dispatched and state changes.
Error Handling: Catch errors during action processing.
Async Operations: Handle tasks like API calls or delayed updates.

জটিল অ্যাপ্লিকেশনে আমাদের অনেক সময় asynchronous ডেটা ফেচ করতে হয়। Redux Toolkit এর createAsyncThunk ফাংশন এটি সহজ করে।

Step-by-Step Example: Fetching API Data

1. Define Async Thunk

import { createAsyncThunk, createSlice } from '@reduxjs/toolkit';

export const fetchUserData = createAsyncThunk(
  'user/fetchUserData',
  async (userId, thunkAPI) => {
    const response = await fetch(`/api/users/${userId}`);
    return response.json();
  }
);

2. Add Thunk to Slice

const userSlice = createSlice({
  name: 'user',
  initialState: { data: null, loading: false, error: null },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchUserData.pending, (state) => {
        state.loading = true;
      })
      .addCase(fetchUserData.fulfilled, (state, action) => {
        state.loading = false;
        state.data = action.payload;
      })
      .addCase(fetchUserData.rejected, (state, action) => {
        state.loading = false;
        state.error = action.error.message;
      });
  },
});

export default userSlice.reducer;

3. Use in Component

import React, { useEffect } from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { fetchUserData } from './userSlice';

const UserProfile = ({ userId }) => {
  const dispatch = useDispatch();
  const { data, loading, error } = useSelector((state) => state.user);

  useEffect(() => {
    dispatch(fetchUserData(userId));
  }, [dispatch, userId]);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return <div>User: {data.name}</div>;
};

export default UserProfile;

Redux DevTools হলো Redux অ্যাপ্লিকেশন ডিবাগিংয়ের জন্য সবচেয়ে কার্যকর টুল। এটি আমাদের actions এবং state পরিবর্তন পর্যবেক্ষণ করতে সাহায্য করে।

Setting Up Redux DevTools

Redux Toolkit already integrates Redux DevTools, so no additional setup is required.

Steps to Use:

Open your app in a browser.
Install the Redux DevTools browser extension.
Inspect the app's state and actions directly in the extension.

Redux DevTools এর মাধ্যমে আমরা যেকোনো সময়ের state এবং actions রিভিউ করতে পারি। এটি ডেভেলপারদের জন্য একটি অসাধারণ টুল।

এই পোস্টটিতে আমরা Redux এবং Redux Toolkit এর অনেক দিক আলোচনা করেছি। Redux Toolkit এর মাধ্যমে আমরা দেখলাম কীভাবে জটিল অ্যাপ্লিকেশনগুলোর state ম্যানেজমেন্ট সহজ করা যায়। এটি আমাদের সময় এবং কোডিং এফোর্ট দুটোই বাঁচায়।

এই পোস্টটি তৈরি করতে AI এর সাহায্য নেওয়া হয়েছে। তবে প্রতিটি অংশের পরিকল্পনা, উপস্থাপনা এবং চূড়ান্ত সম্পাদনা আমার নিজস্ব প্রচেষ্টার ফল।

ধন্যবাদ।

How to Handle Asynchronous Operations

Shajibul Alam Shihab — Mon, 09 Dec 2024 10:57:38 +0000

How to Handle Asynchronous Operations

In TypeScript, we have multiple ways to handle asynchronous operations: callbacks, promises, and async/await. Asynchronous programming allows us to manage operations that could take time, like fetching data from an API, without blocking the execution of other code.

Callbacks

A callback is a function passed as an argument to another function and is executed after a task completes. While callbacks work for simple tasks, they can quickly become unreadable when operations need to be chained.

type Todo = {
  id: number;
  userId: number;
  title: string;
  completed: boolean;
};
const createPromise = (
  id: number,
  callback: (error: Error | null, task: Todo | null) => void
) => {
  fetch(`https://jsonplaceholder.typicode.com/todos/${id}`)
    .then((response) => {
      if (response.ok) {
        return response.json();
      } else {
        throw new Error("failed to load data");
      }
    })
    .then((data) => {
      callback(null, data);
    })
    .catch((error) => {
      callback(error, null);
    });
};

createPromise(1, (error, task) => {
  if (error) {
    console.error(error);
  } else {
    console.log(task);
  }
});

Promises

Promises provide a cleaner approach than callbacks by allowing us to handle asynchronous operations in a more linear way using .then() and .catch() methods. They’re easier to chain but can still get messy with complex operations.

const createPromise = (id: number): Promise<object> => {
  return new Promise<object>((resolve, reject) => {
    const data: object = fetch(
      `https://jsonplaceholder.typicode.com/todos/${id}`
    ).then((response) => response.json());
    if (data) {
      resolve(data);
    } else {
      reject("failed to load data");
    }
  });
};

createPromise(1)
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

Async/Await

Async/await provide a more readable and manageable way of handling asynchronous code compared to promises and callbacks. It lets us write asynchronous code as if it were synchronous, using the async keyword to mark functions as asynchronous and await to pause code execution until the promise resolves. This approach provides improved readability and is easier to debug.

type Todo = {
  id: number;
  userId: number;
  title: string;
  completed: boolean;
};
const getTodo = async (): Promise<Todo> => {
  const response = await fetch("https://jsonplaceholder.typicode.com/todos/1");
  const data = await response.json();
  return data;
};

console.log(getTodo());

Why Use Async/Await?

Improved readability: Async/await is more readable and easier to follow, especially for complex code with multiple asynchronous calls.
Error handling: It allows for simpler error handling with try/catch blocks, instead of multiple .catch() methods.

Thank You

Semantic HTML

Shajibul Alam Shihab — Mon, 09 Dec 2024 10:55:26 +0000

Semantic HTML

What is Semantic HTML?

Semantic HTML uses HTML elements that convey meaning, both to developers and browsers. Instead of using generic elements like <div> and <span>, semantic tags like <header>, <footer>, and <section> clarify the structure of the content.

Why It Matters: The Evolution of HTML

Early HTML (Pre-HTML5):

Relied on <div> and <span> for layout.
Made web pages difficult to read for both humans and machines.

Introduction of HTML5 (2014):

Added semantic elements like <header>, <footer>, <article>, etc.
Promoted cleaner and more accessible code.
Improved machine readability and accessibility for users.

Benefits of Semantic HTML

Accessibility

Assistive technologies like screen readers understand document structure with semantic tags.
Tags help screen readers identify sections, enhancing the experience for users with disabilities.

SEO (Search Engine Optimization)

Semantic tags help search engines interpret content structure and importance.
Tags like <article> and <header> improve content hierarchy and rankings.
<main>, <nav>, <header>, and other elements enhance context and relevance for search engines.

Clean Code Structure

Semantic elements organize code logically, making it easier to read and maintain. Developers can quickly identify content sections, reducing coding errors and improving collaboration across teams.

References or related articles:

Thank You

HTML Element vs HTML Tag

Shajibul Alam Shihab — Mon, 09 Dec 2024 05:47:08 +0000

HTML Element vs HTML Tag

Understanding the Difference

When working with HTML, developers often come across the terms "HTML Tag" and "HTML Element." While they are related, they are not the same thing. In this post, we’ll break down the differences, provide examples, and explain why understanding this distinction matters.

What is an HTML Tag?

An HTML tag is the syntax used to define an element in HTML. Tags are enclosed in angle brackets (< >) and consist of a start tag and, in most cases, an end tag.

Structure:

<tagname>Content</tagname>

Example:

<p>This is a paragraph.</p>

Key Points:

Tags are enclosed in < >.
Tags instruct the browser how to interpret content.
A start tag is required for all elements, and many require an end tag.

What is an HTML Element?

An HTML element refers to the entire structure, which includes the tags, content, and attributes (if any).

Structure:

<tagname attribute="value">Content</tagname>

Example:

<a href="https://example.com">Click here</a>

Key Points:

Elements consist of:
- A start tag.
- Optional attributes.
- Content (if applicable).
- An end tag (if applicable).
Some elements, like <img> or <br>, are self-closing and do not require an end tag.

Comparing HTML Tags and HTML Elements

Here’s a clear example to help you understand the difference:

Example:

<h1>Hello World</h1>

HTML Tag:
- <h1>: The start tag.
- </h1>: The end tag.
HTML Element:
- The complete structure: <h1>Hello World</h1>.
- Includes the tags and the content: "Hello World."

Why This Difference Matters

1. Semantic Understanding:

Knowing the distinction helps you understand how browsers interpret HTML.

2. Debugging:

Clear knowledge of tags vs elements makes it easier to identify and fix issues in your code.

3. Effective Communication:

Using the correct terminology improves collaboration with other developers.

Conclusion

HTML Tag: A syntax that defines an element, enclosed in < >.
HTML Element: The complete structure, which includes tags, content, and attributes.

DEV Community: Shajibul Alam Shihab

Understanding Stack vs Heap Memory (The Way Every Beginner Wishes It Was Explained)

Before We Talk About the Stack...

What Is a Stack?

Introducing the Call Stack

What Is a Stack Frame?

Why Is the Stack So Fast?

The Stack Is Highly Organized

A Simple Way to Think About It

Stack Allocation Is Just Moving a Pointer

Automatic Cleanup

But There's One Limitation...

The Problem the Stack Can't Solve

A Simple Example

What Happens When the Function Returns?

Meet the Heap

The Stack Doesn't Store the Entire Object

Now Everything Makes Sense

If Objects Stay in Memory... Won't Memory Keep Filling Up?

What Is Garbage Collection?

The Most Important Word: Reachable

Garbage Collection Doesn't Run Immediately

How Is This Different From C?

Does JavaScript Have Memory Leaks?

The Big Idea

When Things Go Wrong: Stack Overflow vs Memory Leak

Stack Overflow

But What If the Function Never Stops Calling Itself?

The Problem Isn't Recursion

Memory Leaks

Why It's Called a "Leak"

A Quick Comparison

Common Misunderstandings About Stack and Heap

❌ "Everything inside a function disappears when the function returns."

❌ "Primitive values are always on the Stack, and objects are always on the Heap."

❌ "Garbage Collection removes objects immediately."

❌ "Recursion is bad."

A Special Note for C and C++ Developers

The Mental Model You Should Remember

Step 1: A Function Call Creates a Stack Frame

Step 2: Objects Need a Longer Home

Step 3: Garbage Collection Cleans Unused Objects

Step 4: Problems Happen When We Break These Rules

Stack Overflow

Memory Leak

Stack vs Heap: The Big Picture

The One Thing I Want You to Remember

Final Thoughts

Strings look simple... until they surprise you.

Strings & Text Processing: Text Isn't as Simple as It Looks

Surprise #1: Why Didn't the String Change?

What Does "Immutable" Mean?

Why Design Strings This Way?

A Hidden Cost of Creating New Strings

The Better Approach

Strings Seem Simple... Until They Aren't

Surprise #2: Why Does One Emoji Have a Length of 2?

Computers Don't Understand Letters

Enter UTF-8

Then Why Does JavaScript Say 2?

Wait... Does length Lie?

This Doesn't Only Affect Emojis

Now That We Know How Text Is Stored...

The Everyday String Toolbox

Step 1: Remove Unwanted Spaces

Why Is trim() So Important?

Step 2: Break Text Into Pieces

Step 3: Does This Text Contain Something?

What About indexOf()?

Step 4: Extract Just the Part You Need

Step 5: Build Better Strings

So Far, Everything Has Been Simple...

When Simple Search Isn't Enough

Think of Regex as a Search Rule

A Simple Example

Extracting Every Match

Regex Is Powerful...

...But It's Also Easy to Misuse

Real-World Regex Is Harder Than It Looks

Another Hidden Problem

Wait... Does `length` Lie?

Why Is `trim()` So Important?

What About `indexOf()`?

Mistake #1: Assuming `length` Means "Visible Characters"