Forem: Kathirvel S

I Built a Simple Todo App (and Learned More Than I Expected!)

Kathirvel S — Tue, 07 Apr 2026 14:44:10 +0000

I built a simple Todo List App using JavaScript — something that keeps track of tasks quietly in the background, ready whenever I need it.

👉 You can try it here:

Click Here to Try

This blog isn’t just about what I built — it’s about how it works, especially the JavaScript behind it. I’ll walk you through it in a way that actually makes sense, even if you’re just getting started.

What This Todo App Can Do

Here’s what the app handles:

Add new tasks
Edit existing tasks
Delete tasks
Mark tasks as completed
Save everything using localStorage (even after refresh)

It’s simple, but it covers the core ideas every beginner needs to understand.

Where Everything Lives and Stays

let todos = JSON.parse(localStorage.getItem("vals")) || [];

What’s happening here?

The app checks if there are already saved tasks in localStorage
If yes, it converts them back into a usable array
If not, it starts fresh with an empty list

Think of localStorage as a small shelf where your tasks stay even when you leave and come back.

Locking Things in Place

function savedata() {
    localStorage.setItem("vals", JSON.stringify(todos));
}

This function makes sure your tasks don’t disappear.

It converts the array into a string
Then stores it in the browser

Since localStorage only understands text, we use JSON.stringify() to make it readable.

Rebuilding the Screen Every Time

function renderTodos() {
    logg.innerHTML = "";

Before showing anything, the app clears what’s already on the screen.

Why?
Because instead of updating one item at a time, it rebuilds the entire list cleanly every time something changes.

Going Through Each Task

todos.forEach((todo, index) => {

This loop goes through every task and creates its visual representation.

Showing the Task

const span = document.createElement("span");
span.innerText = todo.text;

Each task is placed inside a span element.

Marking It Done

if (todo.done) span.classList.add("done");

If a task is completed, it gets a line-through style.

Toggling Completion

span.addEventListener("click", () => {
    todo.done = !todo.done;
    savedata();
    renderTodos();
});

Clicking on a task flips its state:

If it was incomplete, it becomes complete
If it was complete, it goes back

Then the app saves and refreshes everything.

Editing a Task

edit.addEventListener("click", () => {
    userinput.value = todo.text;
    editIndex = index;
    btn.innerText = "Update";
});

When you click edit:

The task text is placed back into the input field
The app remembers which task you’re editing
The button changes from "Add" to "Update"

Removing a Task

del.addEventListener("click", () => {
    todos.splice(index, 1);
    savedata();
    renderTodos();
});

This removes the selected task from the list, updates storage, and refreshes the display.

One Function Handling Two Jobs

function handleTask() {

This function decides whether to add a new task or update an existing one.

Avoiding Empty Entries

if (val === "") return;

No empty tasks are allowed.

Adding a New Task

todos.push({ text: val, done: false });

A new task is added as an object with two properties:

text
done

Updating an Existing Task

todos[editIndex].text = val;
editIndex = -1;
btn.innerText = "Add";

The selected task is updated, and the app exits edit mode.

Final Steps

userinput.value = "";
savedata();
renderTodos();

After any change:

The input is cleared
Data is saved
The UI is refreshed

A Small but Important Interaction

userinput.addEventListener("keypress", (e) => {
    if (e.key === "Enter") {
        handleTask();
    }
});

Pressing Enter triggers the same action as clicking the button.
This small addition makes the app feel much smoother to use.

What This Project Really Teaches

Even though the app looks simple, it introduces key concepts:

How to work with the DOM
How to handle user events
How to manage data using arrays and objects
How to store data in the browser
How to keep UI and data in sync

These are the exact building blocks used in larger applications.

Why Building Something Like This Matters

Watching tutorials can only take you so far.

When you build something yourself:

You start understanding why things work
You make mistakes and learn from them
You begin thinking like a developer

This is where real progress happens.

What Would You Add Next?

If you want to take this further, you could try:

Adding due dates
Setting priorities
Creating a dark mode
Improving animations

Each improvement adds another layer of understanding.

Final Thoughts

If you’ve read this far, you’re not just scrolling — you’re trying to understand.

And that matters.

Every line of code in this project represents a step forward. Not just in JavaScript, but in how you approach problems, break them down, and build solutions from scratch.

So here’s something to think about:

What’s the next small idea you’ve been putting off building?

Start it. Keep it simple. Let it grow.

And when you do, you’ll realize this wasn’t just about a todo app — it was about learning how to turn ideas into something real.

Why Is Google Called Google? The Surprising True Story Explained - (Sparked by a Last Notebook Page)

Kathirvel S — Sun, 05 Apr 2026 12:13:43 +0000

One day, I was studying at home, flipping through my institute notes like usual…

You know that moment when you reach the last page of your notebook — wait… pause for a second.

Do you remember what’s on yours?

Don’t overthink it. Just picture it.

Messy, right?

Not the neat, organized stuff from class.
I’m talking about:

Half-written thoughts
Weird doodles
Random numbers
Things you don’t even remember writing

That’s exactly what I saw.

And there it was…

A giant number scribbled across the page.

A “1” followed by… I don’t even know how many zeros.

Looked strange. Almost funny.

If you saw that, what would you do?

Ignore it?
Circle it?
Or just stare and think,

“What was I even trying to write here?”

For me… it triggered a question.

Where have I seen something like this before?

And suddenly — it clicked.

Google.

Yeah, that Google.

It All Started With a Massive Number

Before “Google” existed, there was a word called “googol.”

No, that’s not a typo.

A googol is a mathematical term. It means:

1 followed by 100 zeros

Let’s make this fun…

Try counting the zeros in your head.

Go on… start.

…Still counting?

Exactly 😄

Here it is:

1,00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Feels unreal, right?

This number is ridiculously huge. Bigger than most things we can even imagine.

Why That Word?

Now imagine this scene.

Two PhD students at Stanford — Larry Page and Sergey Brin — sitting and thinking:

“How do we organize the entire internet?”

Not just a few websites. Not just popular pages.

Everything.

If you were in their place, what would you name it?

Something serious?
Something technical?
Or something that actually feels big?

They chose something massive. Something limitless.

That’s where “googol” came in.

The Twist That Changed Everything

Now here’s where it gets interesting.

While deciding the name, someone misspelled “googol” as:

Google

Let me ask you something—

If you noticed that typo… would you fix it?

Be honest.

Most of us would.

But they didn’t.

They looked at it… and thought:

“Wait… this actually sounds better.”

It felt:

Simpler
Catchier
Easier to remember

And honestly?

Say it out loud once: Google

Feels smooth, right?

That’s why they kept it.

Imagine If It Stayed “Googol”… 😬

Let’s play a quick game.

Say this sentence out loud:

“Just Google it”

Now try:

“Just Googol it”

Yeah… something feels off 😅

That tiny spelling change made a huge difference.

It made the brand feel:

More human
More playful
Less intimidating

And that’s powerful.

Because people don’t just use tools…

They connect with what feels easy.

Why the Name Actually Matters More Than You Think

Here’s a quick challenge for you:

Think of the last time you searched for something.

Did you say:

“Let me internet-search that”
“Let me web-query this”

Nope.

You said:

“Let me Google it.”

That’s not just a name anymore.

That’s behavior.

That’s habit.

That’s branding at its peak.

A Quick Reality Check

Next time you open Google, pause for a second.

Before typing anything…

Think about this:

You’re about to search through something inspired by the idea of almost infinite information.

Whether it’s:

A random late-night question
A bug you’re stuck on
Or something you’re just curious about

You’re tapping into something massive.

And weirdly enough…

The name still fits perfectly.

The Real Lesson Behind the Name

Let’s make this personal.

Have you ever:

Misspelled something and felt embarrassed?
Made a small mistake and tried to hide it?
Thought something wasn’t “perfect enough”?

Now think again.

Google exists because of a mistake.

And not just any mistake…

A typo.

The name worked because:

It’s simple
It’s unique
It sparks curiosity

And most importantly…

It sticks.

Before You Scroll Away…

Let’s come back to where we started.

That last page of the notebook.

The thing made me to write this blog

You imagined yours earlier, right?

Now I want you to actually do something.

Close this tab for a moment.

Yes, seriously.

Go grab your notebook.

Flip to the last page.

And look at it properly this time.

What do you see?

A random idea?
A weird sketch?
Something incomplete?

Don’t ignore it.

Because sometimes…

The most interesting things aren’t in the main pages.

They’re hidden at the end.

Who knows?

You might just find your own unexpected idea waiting there…

Just like a random number that once turned into Google 😉

Stop Messing With APIs: How fetch() and .json() Actually Work

Kathirvel S — Thu, 02 Apr 2026 12:42:06 +0000

Imagine you’re in NASA mission control.

Artemis 2 is about to launch — humanity’s next giant leap in space.

Engineers and scientists are buzzing, every system needs to work perfectly.

Image source:NASA

Now, imagine you’re the coder responsible for getting live telemetry from that spacecraft.

If you don’t understand how data travels, how it’s formatted, or how to handle it, you’re in serious trouble.

Welcome to the world of fetch() and .json() — your mission control for API data.

Look at This Code

fetch("https://api.openweathermap.org/data/2.5/weather?q=Chennai&appid=YOUR_API_KEY&units=metric")
  .then(res => res.json())
  .then(data => console.log(data));

Looks small and simple, right?

But every part is like a critical system on Artemis 2.

Skip one step, and your code could “crash” — or worse, give you garbage data.

Step 1: `fetch()` — Launching the Rocket

fetch(URL)

This is your launch command.

Image source:NASA

You ask the server:

“Give me the latest Chennai weather.”

Immediately,

you get a Promise

Think of it as your telemetry link: Artemis 2 is in orbit, but the data isn’t here yet.

Logging it:

console.log(fetch(URL));

Output:

Promise { <pending> }

The rocket is flying, data is streaming — your program continues running.

Mission control doesn’t freeze while waiting, and neither does your code.

Step 2: `res` — The Sealed Capsule

.then(res => res.json())

res is the spacecraft capsule full of data — sealed, floating in orbit.

Image source:NASA

It contains:

Response {
  type: "cors",
  url: "https://api.openweathermap.org/data/2.5/weather?q=Chennai&appid=YOUR_API_KEY&units=metric",
  ok: true,
  status: 200,
  statusText: "OK",
  body: ReadableStream,
  headers: Headers {},
  redirected: false
}

Notice body is a stream, not a usable object.

Trying to grab res directly is like trying to read Artemis 2’s instruments without opening the capsule — useless.

Step 3: Why APIs Can’t Send JS Objects Directly

Let’s simplify this: imagine sending a live robot to a friend’s house.

You can’t just send the robot as it exists in your memory — it won’t survive the journey.

You need a universal format to travel safely.

That’s what JSON does for APIs.

Language-Agnostic: JavaScript objects only exist in JS. JSON can be understood by any language — Python, Java, or even C.
Network-Friendly: Networks transmit bytes and strings, not in-memory objects. A JS object is like trying to send a full robot over the internet — impossible.
Standardized & Lightweight: JSON is readable, compact, and structured. It’s the “telemetry language” of APIs — predictable and safe for any client to read.

Example JSON:

{
  "coord": { "lon": 80.2785, "lat": 13.0878 },
  "weather": [{ "id": 803, "main": "Clouds", "description": "broken clouds", "icon": "04d" }],
  "main": { "temp": 32.5, "feels_like": 36.1, "humidity": 70 },
  "wind": { "speed": 5.2, "deg": 240 },
  "clouds": { "all": 75 },
  "name": "Chennai",
  "cod": 200
}

Skip JSON, and your mission is doomed — your telemetry becomes gibberish.

Step 4: `.json()` — Opening the Capsule

res.json() reads the full stream and converts it into a JavaScript object.

Image source:NASA

Before .json():

"{\"name\":\"Chennai\",\"main\":{\"temp\":32.5}}"

After .json():

{
  name: "Chennai",
  main: { temp: 32.5 }
}

Now you can access:

data.name         // "Chennai"
data.main.temp    // 32.5

Skipping .json() is like trying to pull Artemis 2’s data straight from orbit without opening the instruments — rookie mistake.

Step 5: Why `.json()` Returns a Promise

.json() doesn’t give you data immediately because:

The Stream Arrives in Chunks: Data is like telemetry packets from Artemis 2. You can’t use it until all packets arrive.
Parsing Takes Time: Large responses need milliseconds to convert into a JS object safely.
Promise Represents Future Data: .json() returns a Promise that resolves once the data is fully ready.

Chain it safely:

fetch(URL)
  .then(res => res.json()) // returns a Promise
  .then(data => console.log(data)); // safe to use after parsing

No promise? Your app freezes like mission control without power.

Step 6: Full Mission Flow

Image source:NASA

fetch() → Launch Artemis 2.
.then(res => res.json()) → Capsule reaches orbit, open telemetry, decode data.
.then(data => ...) → Analyze and use it safely.

Example final output:

{
  coord: { lon: 80.2785, lat: 13.0878 },
  weather: [{ id: 803, main: "Clouds", description: "broken clouds", icon: "04d" }],
  main: { temp: 32.5, feels_like: 36.1, temp_min: 32, temp_max: 33, pressure: 1010, humidity: 70 },
  visibility: 5000,
  wind: { speed: 5.2, deg: 240 },
  clouds: { all: 75 },
  dt: 1680345600,
  sys: { type: 1, id: 9218, country: "IN", sunrise: 1680306000, sunset: 1680350400 },
  timezone: 19800,
  id: 1264527,
  name: "Chennai",
  cod: 200
}

Step 7: Mental Model — Don’t Crash Your Mission

Skipping .json() or ignoring promises is like asking Artemis 2 to dock without telemetry or running mission control blind.

Image source:NASA

You’ll stare at errors, confused, wondering why nothing works.

Treat .json() and promises as your instruments and sensors — essential for a successful mission.

Conclusion — The NASA Analogy

Every time you write:

fetch(...).then(res => res.json()).then(data => ...)

Think:

You’re NASA mission control.
The API is Artemis 2 in orbit.
.json() is opening the capsule and decoding telemetry.
Chaining .then() ensures you only act when data is verified and ready.

Master this, and your web apps won’t just work — they’ll land safely, every time.

Ignore it, and your app crashes faster than an untested rocket launch.

This is fetch() and .json() — your API mission control.

Don’t be the coder who ignores the telemetry.

JavaScript Promises: Transform Your Async Code from Messy to Clean

Kathirvel S — Sun, 29 Mar 2026 08:31:59 +0000

It’s late at night.

You open Instagram just for a quick scroll.
The app loads… but something feels off.

The profile takes time.
The feed shows up half-loaded.
Likes appear late.
Comments suddenly pop in after a delay.

For a moment, it feels broken.

Now imagine you’re the developer behind that experience.

Somewhere in your code:

Data is coming late
Steps are not properly ordered
One thing depends on another… but the flow isn’t clear

This is exactly where most developers struggle — not with writing code, but with controlling when things happen.

Let’s make this simple

Step 1: The “Do Everything in Order” Phase (Synchronous JavaScript)

In the beginning, everything feels easy.

Your code runs top to bottom. No surprises.

console.log("1. User");
console.log("2. Feed");
console.log("3. Likes");

Output:

1. User
2. Feed
3. Likes

Nice and predictable.

But imagine this:

What if loading the user takes 3 seconds?

Everything below just waits.

Your app is now just… staring at the user.

Step 2: “Let’s Not Make Users Wait” (Asynchronous JavaScript)

So you try something smarter.

console.log("Start");

setTimeout(() => {
  console.log("User loaded");
}, 2000);

console.log("Keep using app...");

Output:

Start
Keep using app...
User loaded

Now your app feels alive.

Things are loading in the background.

But there’s a small problem:

Things don’t happen in order anymore.

Step 3: “Okay, I Want Control” (Callbacks)

You decide:

“I want things in order… but still async.”

function loadUser(next) {
  setTimeout(() => {
    console.log("User");
    next();
  }, 1000);
}

function loadFeed(next) {
  setTimeout(() => {
    console.log("Feed");
    next();
  }, 1000);
}

loadUser(() => {
  loadFeed(() => {
    console.log("Done");
  });
});

Output:

User
Feed
Done

Works well.

But if you keep adding steps…

Step 4: The “Why Is This So Deep?” Moment (Callback Hell)

loadUser(() => {
  loadFeed(() => {
    setTimeout(() => {
      console.log("Likes");
      setTimeout(() => {
        console.log("Comments");
        console.log("All done");
      }, 1000);
    }, 1000);
  });
});

It works.

But reading it feels like going down a staircase.

Not fun. Easy to mess up.

Step 5: A Cleaner Way (Promises)

Now let’s clean things up.

function loadUser() {
  return Promise.resolve("User");
}

function loadFeed() {
  return Promise.resolve("Feed");
}

Now write flow like this:

loadUser()
  .then((res) => {
    console.log(res);
    return loadFeed();
  })
  .then((res) => {
    console.log(res);
    console.log("Done");
  });

Output:

User
Feed
Done

Much better.

Flat. Easy to follow.

Going Deeper: What a Promise Really Is

A Promise is not just a cleaner syntax.

It’s an object that represents a value that will be available later.

It has three states:

Pending → still waiting
Fulfilled → success (you get data)
Rejected → failed (you get error)

Here’s a simple example:

const promise = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("Data loaded");
    // reject("Something went wrong");
  }, 1000);
});

promise
  .then((data) => console.log(data))
  .catch((err) => console.log(err));

Why this matters:

resolve() moves the promise to success
reject() moves it to failure
.then() handles success
.catch() handles errors

Small but Powerful Features of Promises

1. Chaining keeps things clean

Each .then() passes data to the next:

Promise.resolve(1)
  .then((num) => num + 1)
  .then((num) => num + 1)
  .then((num) => console.log(num)); // 3

No nesting. Just flow.

2. Handling multiple async tasks

Sometimes tasks don’t depend on each other.

You can run them together:

Promise.all([
  Promise.resolve("User"),
  Promise.resolve("Feed"),
  Promise.resolve("Likes"),
]).then((res) => console.log(res));

Output:

["User", "Feed", "Likes"]

Everything runs in parallel.

Faster and efficient.

3. First result wins

Promise.race([
  new Promise((res) => setTimeout(() => res("Fast"), 1000)),
  new Promise((res) => setTimeout(() => res("Slow"), 3000)),
]).then(console.log);

Output:

Fast

Useful for timeouts or fastest responses.

Step 6: The Easiest Way (Async/Await)

Now the cleanest version:

async function run() {
  const user = await loadUser();
  console.log(user);

  const feed = await loadFeed();
  console.log(feed);

  console.log("Done");
}

run();

Same result.

But this feels natural.

Like reading normal code.

Where Promises Are Really Used (And Why They Matter)

This is not just theory.

Promises are used everywhere in real applications.

Think about apps like Instagram, YouTube, or Netflix.

When you open them:

Your profile is fetched
Your feed is loaded
Images and videos load separately
Likes and comments arrive later

All of these happen asynchronously.

Some steps depend on others:

You need user data before showing a personalized feed
You need posts before loading comments
You need authentication before API calls

Promises help manage all this without chaos.

They let your app stay fast, responsive, and organized at the same time.

The Real Upgrade: From “It Works” to “It Feels Smooth”

Here’s the shift that matters.

At first, you write code just to make things work.

Then things get a little complex.

Suddenly:

Order breaks
Code gets nested
Bugs become harder to trace

That’s when you realize:

This isn’t just about code.
It’s about flow.

Every step in your app is a small event.

If those events are not clearly controlled:

Data shows up late
UI feels inconsistent
Users feel something is off

But when you structure it right:

Things load in the right order
Background work doesn’t block the app
Code stays readable even as it grows

That’s the real role of Promises and async/await.

They don’t just fix syntax.

They fix how your app behaves.

And when the behavior is right, the user never notices the complexity behind it.

It just feels smooth.

Stop Misreading JavaScript: The Truth About Single Thread, Sync, and Async

Kathirvel S — Fri, 27 Mar 2026 12:16:12 +0000

Have you ever paused mid-code and thought:

“Wait… how is this doing so many things at once?”

Be honest — you’ve had that moment. We all have.

It feels like JavaScript is multitasking like a pro.
But what if I told you…

It’s actually not.

Let’s peel that layer back together

The Truth: JavaScript is Single-Threaded

Here’s the deal — simple and clear:

JavaScript can do only one thing at a time

No juggling. No parallel cooking. Just… one task.

Picture this:

You’re alone in a kitchen with one burner.

You can:

Boil noodles
Fry eggs
Make coffee

But not all at once.

So now you might be thinking…

“Then why doesn’t my app feel slow?”

Good question. Stay with me.

So Why Does JavaScript Feel Fast?

Because JavaScript is smart about waiting.

It doesn’t sit idle like:

“Let me just stare at this loading thing…”

Instead, it says:

“This will take time? Cool. I’ll come back later.”

And that’s where these behind-the-scenes players step in:

Call Stack → where your code runs
APIs (browser/Node) → handle time-taking stuff
Queue → waiting area
Event Loop → decision maker

Think of it like a system, not just a language.

Let’s Play a Quick Game

Look at this:

console.log("Mixing chemicals");

setTimeout(() => {
  console.log("💣 BOOM!");
}, 0);

console.log("Writing notes");

Pause for a second.

What do you think prints first?

Most people go with:

Mixing chemicals
💣 BOOM!
Writing notes

But here’s what actually happens:

Mixing chemicals
Writing notes
💣 BOOM!

Gotcha? 😄

What Just Happened?

Even with 0ms, JavaScript didn’t rush.

It basically said:

“Not now. I’ll handle this after I finish what I’m doing.”

That “later” is the async system kicking in.

Sync vs Async — Feel It, Don’t Memorize It

Synchronous (Sync)

Everything happens in order. No surprises.

Like waiting in line for chai ☕

console.log("Order chai");
console.log("Make chai");
console.log("Drink chai");

You already know the output.

Predictable. Calm. Straightforward.

Asynchronous (Async)

Now imagine this:

You order food… and instead of waiting awkwardly…

You:

Sit down
Scroll your phone
Chat with a friend

And then your food arrives

That’s async.

A More Real Example

You’re uploading a photo 📸

console.log("User clicks upload");

uploadImage(() => {
  console.log("Image uploaded");
});

console.log("User keeps scrolling");

Now think:

Should the app freeze until upload finishes?

Nope.

Actual flow:

User clicks upload
User keeps scrolling
Image uploaded

Smooth experience. No frustration.

Let’s Make It Personal

Imagine sending a risky message…

console.log("Typing message...");

setTimeout(() => {
  console.log("Message sent 💌");
}, 2000);

console.log("Still thinking if this is a bad idea...");

What happens?

Typing message...
Still thinking if this is a bad idea...
Message sent 💌

Yeah… no going back now 😄

What’s Happening Behind the Scenes?

Let’s simplify it:

Your code starts running (Call Stack)
Time-taking stuff gets handled elsewhere (APIs)
When done → it waits in a queue
Event Loop checks: “Can I run this now?”
If yes → it runs

That’s the whole “magic trick”.

Want to Understand It Deeper?

This is just the surface-level intuition.
If you want a clearer mental model with examples and visuals,
I’ve explained everything in detail in my blog.

👉 Want a deeper dive into how this actually works behind the scenes? You can check out my full blog here:

Click here to view - Call Stack, Stack Queue and Event Loop Explained

The Event Loop (In Human Terms)

Imagine a strict manager:

“Are you done with your current task?”

If not:

Nothing new happens

If yes:

Next task comes in

No chaos. Just discipline.

Sync vs Async — Quick Feel Check

Feature	Sync	Async
Blocks flow	Yes	No
Feels fast	Not really	Yes
Easy to read	Yes	Sometimes tricky
Used in real apps	Rarely	Almost always

One Last Brain Teaser

Try this:

console.log("A");

setTimeout(() => {
  console.log("B");
}, 1000);

setTimeout(() => {
  console.log("C");
}, 0);

console.log("D");

Don’t rush.

What’s your guess?

Actual output:

A
D
C
B

If that made you pause for a second…

Good. That means you’re getting it.

The Big Takeaway

JavaScript is:

Single-threaded
Smart about waiting
Powered by the event loop

That’s why it feels fast.

Before You Scroll Away

Next time your code acts weird…

Don’t blame JavaScript immediately

Ask yourself:

“Is this sync or async?”
“Where is this running right now?”

That small shift changes everything.

Final Thought

JavaScript isn’t hard.

It just has its own way of thinking.

Once you tune into that…

Things stop feeling random — and start making sense.

And next time someone says:

“JavaScript is single-threaded”

“Yeah… but there’s more to the story.”

If this challenged the way you think even a little…

good.

Because that’s how you actually grow as a developer.

And next time your code runs “out of order”…

You won’t panic.

You’ll just smirk and say:

“Yeah… I know why.”

JavaScript Closures Explained Simply

Kathirvel S — Thu, 26 Mar 2026 13:32:50 +0000

Let’s be honest.

Closures in JavaScript sound scary at first.
You’ve probably seen definitions like:

“A closure is a function that retains access to its lexical scope…”

And your brain immediately goes: Nope.

But here’s the truth — closures are not complicated. You’re already using them. You just don’t realize it yet.

So let’s break it down slowly, clearly, and in a way that actually sticks.

First — don’t scroll

Look at this code.

function outer() {
  let name = "Alex";

  return function inner() {
    console.log(name);
  };
}

const fn = outer();
fn();

What do you think the output is?

Don’t skip. Think.

Now imagine you bet money on your answer.

Output:

Alex

If that surprised you even a little… good. You’re in the right place.

Now here’s the real question

Why is name still available?

outer() is already done. Gone. Finished.

So why didn’t name disappear with it?

If your answer is:

“Because JavaScript is weird”

No. That’s just avoiding the truth.

Or worse — memorizing without understanding.

This is where closures hit you

A closure means:

A function remembers variables from where it was created — not where it runs.

Read that again.

Not where it runs.
Where it was created.

If that still feels abstract, don’t worry — I’m going to corner you with examples.

Still not convinced? Let’s push you

Real scenario: Login system

function createLogin(username, password) {
  return function (inputPassword) {
    if (inputPassword === password) {
      console.log(`Welcome ${username}`);
    } else {
      console.log("Wrong password");
    }
  };
}

const login = createLogin("Sam", "pass123");

login("pass123");
login("123");

Output:

Welcome Sam
Wrong password

Now answer this:

Where is password stored?

Not global
Not inside login
Not accessible anywhere

Yet it still works.

And no, it’s not “saved somewhere magically.”

That’s closure.

And if that didn’t click yet, don’t worry — I’m not done with you.

Let’s corner you a bit

Try this:

console.log(login.password);

Before you run it — predict it.

Output:

undefined

So…

You can’t access it
But the function can

Sounds like magic?

It’s not magic. It’s memory + scope working together.

Real-world situation: You click a button

Let’s say you're tracking clicks.

function createClickTracker() {
  let count = 0;

  return function () {
    count++;
    console.log(`Clicked ${count} times`);
  };
}

const click = createClickTracker();

click();
click();
click();

Output:

Clicked 1 times
Clicked 2 times
Clicked 3 times

Now don’t just read.

Answer this:

Why is count not resetting to 0?

Pause. Actually think.

Because you're not creating count again.
You're reusing the same closed-over variable.

Let’s make it uncomfortable

What if I do this:

const click1 = createClickTracker();
const click2 = createClickTracker();

click1();
click1();

click2();

Before you scroll — predict it.

Output:

Clicked 1 times
Clicked 2 times
Clicked 1 times

Now think carefully.

If closures were “shared memory”… this wouldn’t happen.

Each function has its own private world.

Yes — like separate tabs in your browser.

Real app logic: Shopping cart

function createCart() {
  let items = [];

  return {
    add(item) {
      items.push(item);
      console.log(`${item} added`);
    },
    view() {
      console.log(items);
    }
  };
}

const cart = createCart();

cart.add("Laptop");
cart.add("Phone");
cart.view();

Output:

Laptop added
Phone added
["Laptop", "Phone"]

Now I dare you:

console.log(cart.items);

Before running it — what do you expect?

Output:

undefined

So let me ask you:

If you can’t access items, how is it still updating?

Because it lives inside a closure.

Not global. Not exposed. Not reachable.

Hidden — but alive.

Now let’s catch a bug (you’ve probably made this)

for (var i = 1; i <= 3; i++) {
  setTimeout(function () {
    console.log(`Order ${i}`);
  }, 1000);
}

What do you expect?

Be honest.

Order 1
Order 2
Order 3

What actually happens?

Order 4
Order 4
Order 4

Yeah. That bug.

Don’t say “I wouldn’t make that mistake.”
You either already have — or you will.

Fix it using closure

for (var i = 1; i <= 3; i++) {
  (function (order) {
    setTimeout(function () {
      console.log(`Order ${order}`);
    }, 1000);
  })(i);
}

Output:

Order 1
Order 2
Order 3

Each loop creates a new memory.

Same code pattern. Different outcome.

That’s the twist closures bring.

Or use modern JS (yes, this is easier)

for (let i = 1; i <= 3; i++) {
  setTimeout(function () {
    console.log(`Order ${i}`);
  }, 1000);
}

Same correct output.

Because let creates a new scope every time.

Different keyword. Completely different behavior.

Pause. Don’t scroll yet.

If I ask you now:

What is a closure?

Don’t repeat a definition.

Say it like a developer.

Say it like you actually understand it.

The version you should remember

A closure is when a function carries its data with it, even after the original function is gone.

Not stored globally.
Not recreated.
Carried.

Quick self-check (no cheating)

What will this print?

function createDiscount(discount) {
  return function (price) {
    return price - price * discount;
  };
}

const discount10 = createDiscount(0.1);

console.log(discount10(200));

Don’t rush. Think.

Output:

If you got that right, you’re not guessing anymore.

If you didn’t — good. That means you’re actually learning instead of memorizing.

Final reality check

Closures are not some “advanced topic.”

They are used in:

React hooks
Event listeners
API handlers
Timers
State management

So if you skip this…

You’re not skipping theory.
You’re skipping how JavaScript actually works.

One last push

Next time you see:

Function inside function
Returned function
Hidden variables
Values that “don’t reset”

Don’t ignore it.

Stop and ask:

“What is this function remembering?”

That question alone will level you up.

And now you actually understand closures — not just pretend to.

JavaScript Dates Finally Make Sense (Here’s How)

Kathirvel S — Wed, 25 Mar 2026 14:23:28 +0000

Okay, quick question…

Have you ever written some JavaScript code, checked the date… and thought:

“Wait… WHY is it showing the wrong day?? ”

Yeah. We’ve all been there.

Dates in JavaScript have a reputation. They confuse beginners, annoy intermediate devs, and even make experienced developers double-check their code twice.

But today? We’re flipping the script.

By the end of this, you won’t just understand JavaScript dates—you’ll actually enjoy working with them (no kidding).

First Thing You Need to Know (This Changes Everything)

JavaScript doesn’t see dates like “March 25, 2026”.

Instead, it thinks like this:

“How many milliseconds have passed since Jan 1, 1970?”

Yep. That’s how your computer sees time.

Weird? A little.
Powerful? Absolutely.

But wait… why 1970? Why not 2000? Or 1900?

Why JavaScript Counts Time from 1970 (The Real Reason)

Alright, this is where things get interesting.

That starting point—January 1, 1970—is called the Unix Epoch.

Back in the early days of computing, engineers needed a simple, consistent way to represent time across different systems.

Instead of dealing with:

months (which have different lengths)
leap years (extra chaos )
time zones (total madness )

They thought:

“Let’s just count time as a number.”

So they picked a fixed starting point:

📍 Jan 1, 1970, 00:00:00 (UTC)

From there, every moment is just:

number of seconds (or milliseconds) since that point

Why 1970 Specifically?

Good question. It wasn’t random.

That’s around the time Unix systems were being developed
It was a “modern enough” date for computers back then
It made calculations easier within system limits

And since JavaScript was created later, it simply adopted the same system.

What Does This Look Like in JavaScript?

Let’s see it in action:

let now = new Date();
console.log(now.getTime());

Output:

1763788215000

That big scary number?

That’s the number of milliseconds since Jan 1, 1970

What About Dates Before 1970?

Yep, JavaScript handles those too.

let oldDate = new Date("1960-01-01");
console.log(oldDate.getTime());

Output:

-315619200000

Negative value = time before 1970.

So yes… JavaScript can technically time travel to the past too 😄

Why This System Is Actually Genius

At first glance, it feels unnecessary. But this approach makes things:

Easy to compare dates
Fast for computers to calculate
Consistent across systems
Less error-prone than manual date math

Instead of comparing messy strings, JavaScript compares clean numbers.

And machines LOVE that.

Let’s Create Your First Date

Try this in your console:

let now = new Date();
console.log(now);

Output:

Wed Mar 25 2026 10:30:15 GMT+0530 (India Standard Time)

Now You just created a real-time date.

Feels like magic, right?

Want to Control Time? Let’s Do It

You’re not stuck with the current time. You can create your own:

let myDate = new Date("2026-03-25");
console.log(myDate);

Output:

Wed Mar 25 2026 05:30:00 GMT+0530

Now let’s get a bit more specific:

let detailedDate = new Date(2026, 2, 25, 10, 30, 0);
console.log(detailedDate);

Output:

Wed Mar 25 2026 10:30:00 GMT+0530

Hold on… why is March = 2?

Because JavaScript decided:

0 = January
1 = February
2 = March

Not logical. But hey… we adapt and move on 😄

Let’s Break the Date Open

Now the fun part—pulling data out:

let today = new Date();

console.log(today.getFullYear());
console.log(today.getMonth());
console.log(today.getDate());
console.log(today.getDay());

Output:

Let’s decode that like detectives

2026 → year
2 → March
25 → actual date
3 → Wednesday

Quick trap (don’t fall into it):

getDate() → gives the date
getDay() → gives the weekday

Mix these up once… and you’ll never forget again 😅

Making Dates Look Good (Because Ugly Outputs Hurt)

Let’s fix it:

let date = new Date();

console.log(date.toDateString());
console.log(date.toLocaleDateString());

Output:

Wed Mar 25 2026
25/3/2026

Better… but we can go premium:

let options = { year: 'numeric', month: 'long', day: 'numeric' };
console.log(date.toLocaleDateString('en-IN', options));

Output:

March 25, 2026

Now THAT looks like production code

Time to Play with Time

Let’s grab live time values:

let time = new Date();

console.log(time.getHours());
console.log(time.getMinutes());
console.log(time.getSeconds());

Output:

10
30
15

You’re basically building your own clock now.

Date Battle: Which One Comes First?

let date1 = new Date("2026-03-25");
let date2 = new Date("2026-04-01");

console.log(date1 < date2);

Output:

true

JavaScript secretly converts both into numbers and compares them.

Sneaky… but useful.

Time Travel (Yes, You Can)

Let’s jump to tomorrow:

let today = new Date();
today.setDate(today.getDate() + 1);

console.log(today);

Output:

Thu Mar 26 2026 ...

Go back a week:

today.setDate(today.getDate() - 7);
console.log(today);

Output:

Thu Mar 19 2026 ...

You’re officially a time traveler now 🧭

Let’s Build Something Cool: Live Digital Clock

Now we stop learning… and start building

Step 1: Create the UI

<h1 id="clock">00:00:00</h1>

Right now, it’s just a boring static text.

But not for long…

Step 2: Write the Brain

function updateClock() {
  let now = new Date();

  let hours = now.getHours();
  let minutes = now.getMinutes();
  let seconds = now.getSeconds();

  document.getElementById("clock").innerText =
    hours + ":" + minutes + ":" + seconds;
}

This function grabs the current time and injects it into your HTML.

Step 3: Make It Alive

setInterval(updateClock, 1000);

Now your function runs every second.

Which means…

Your clock is LIVE

But Wait… Something Looks Off

You might see:

10:3:5

That’s… not pretty.

Let’s fix it

Step 4: Make It Look Professional

function formatTime(value) {
  return value < 10 ? "0" + value : value;
}

function updateClock() {
  let now = new Date();

  let hours = formatTime(now.getHours());
  let minutes = formatTime(now.getMinutes());
  let seconds = formatTime(now.getSeconds());

  document.getElementById("clock").innerText =
    hours + ":" + minutes + ":" + seconds;
}

setInterval(updateClock, 1000);

Output:

10:03:05

Now THAT looks clean

You Made It (Seriously, That’s Big)

Look at what you just did:

✔ Created dates
✔ Controlled time
✔ Extracted values
✔ Formatted output
✔ Compared dates
✔ Traveled through time
✔ Built a live project

That’s not beginner stuff anymore.

Before You Go…

Next time JavaScript messes up your date…

Don’t panic.

Just smile and say:

“Ahhh… I know your tricks now 😏”

And fix it like a pro.

If this made things click for you even a little…
you’re already ahead of a LOT of developers.

Keep building. Keep breaking things. That’s how you grow!

Mastering createElement in JavaScript (In a Way That Actually Sticks)

Kathirvel S — Tue, 24 Mar 2026 14:48:51 +0000

Let’s be honest.

Writing static HTML is easy.
But the moment someone says

“make it dynamic,”

things start getting confusing.

That’s exactly where createElement() becomes your friend.

Instead of just writing HTML, you start building it live using JavaScript. And once you get this, everything—from to-do apps to real-world projects—starts making sense.

Let’s build this step by step, like you're actually doing it.

First, What Are We Even Doing?

We’re going to:

Create elements using JavaScript
Add content inside them
Style them a bit
Place them exactly where we want (before, after, inside)
And understand what’s happening behind the scenes

Step 1: Create Something (But It’s Invisible)

let heading = document.createElement("h1");

Right now, nothing shows up.

What’s happening behind the scenes?

The browser creates an object in memory (inside the DOM)
This object represents an <h1> element
But it is not attached to the page yet

Think of it like building a LEGO piece in your hand… but not placing it on the board.

Step 2: Give It Life (Add Text)

heading.textContent = "Hello, World!";

Now your element actually has meaning.

Behind the scenes:

A text node is created
That text node is placed inside the <h1> element
The DOM structure now looks like:

<h1>Hello, World!</h1>

Still invisible though, because it's not connected to the document.

Step 3: Make It Look Decent

heading.style.color = "blue";
heading.style.fontSize = "40px";

Behind the scenes:

You’re modifying the element’s inline style object
The browser updates its internal CSS representation
But again—since it's not in the document, nothing renders yet

So yes, you're styling it… but it’s still off-screen.

Step 4: Put It on the Page

document.body.appendChild(heading);

Now it finally shows up.

Behind the scenes:

The <h1> node is attached to the DOM tree
The browser detects a DOM change
It triggers:
- Reflow (layout calculation)
- Repaint (drawing pixels on screen)

Output:

Hello, World!

That moment when it appears? That’s the browser saying:

“Okay, now I know where to render this.”

Creating Multiple Elements (The Smart Way)

Real apps don’t create just one element—they create many.

let fruits = ["Apple", "Banana", "Mango"];

let ul = document.createElement("ul");

fruits.forEach(function(fruit) {
    let li = document.createElement("li");
    li.textContent = fruit;
    ul.appendChild(li);
});

document.body.appendChild(ul);

Output:

• Apple
• Banana
• Mango

Behind the scenes:

Each loop creates a new <li> node
Text nodes are inserted into each <li>
All <li> elements are attached to <ul>
Then <ul> is added to the DOM in one operation

Efficient and clean.

Placement Control (This Is Where It Gets Powerful)

Appending everything at the end is basic.

Let’s control exactly where things go.

Case 1: Add Before an Element

<p id="target">I am the target</p>

let newPara = document.createElement("p");
newPara.textContent = "I appear before the target.";

let target = document.getElementById("target");

document.body.insertBefore(newPara, target);

Output:

I appear before the target.
I am the target

Behind the scenes:

The browser finds the target node
Inserts the new node right before it in the DOM tree
Internally, it just adjusts node positions—no full rebuild

Case 2: Add After an Element

let newDiv = document.createElement("div");
newDiv.textContent = "I come after the target.";

let target = document.getElementById("target");

target.insertAdjacentElement("afterend", newDiv);

Output:

I am the target
I come after the target.

Behind the scenes:

The browser calculates the position after the target node
Inserts your element exactly there in the DOM hierarchy

Case 3: Insert Exactly Where You Want

target.insertAdjacentElement("beforebegin", newDiv); // before element
target.insertAdjacentElement("afterbegin", newDiv);  // inside (top)
target.insertAdjacentElement("beforeend", newDiv);   // inside (bottom)
target.insertAdjacentElement("afterend", newDiv);    // after element

Behind the scenes:

You are giving precise instructions to the DOM:

Insert relative to this node
Update only that part of the tree

This is efficient and powerful.

Let’s Make It Interactive

let button = document.createElement("button");
button.textContent = "Click Me";

document.body.appendChild(button);

Output:

[ Click Me ]

button.addEventListener("click", function() {
    alert("You clicked the button!");
});

Output:

Click →

You clicked the button!

Behind the scenes:

An event listener is attached
The browser listens for a click event
When triggered, your function runs

This is the foundation of interactivity on the web.

Common Mistakes (Everyone Hits These Once)

Created element but forgot appendChild() → nothing appears
Appended to wrong parent → layout issues
Typo in tag name → unexpected behavior
Overusing innerHTML instead of textContent

Quick Recap

createElement() → creates node in memory
textContent → adds text node
appendChild() → attaches to DOM
insertBefore() → places before
insertAdjacentElement() → precise placement

Your Turn

Try this:

Create a heading
Create 3 paragraphs using a loop
Insert one before the heading and one after

If you can do that without looking back, you’ve understood this properly.

Final Thought

At first, this feels like just creating elements.

But what you’re really learning is how the browser builds and updates a page internally.

Once this clicks, frameworks like React or Vue start making a lot more sense.

Now go try things. Break them. Fix them.

That’s where real learning happens.

Are You Addicted to Notifications? The Tech Behind It

Kathirvel S — Sun, 22 Mar 2026 06:04:03 +0000

Stop for a second… did your phone just buzz or light up while you were reading this? Chances are, you can’t resist checking it.
And there’s a reason:

it’s not just you, it’s the technology itself.

Let’s be honest—how many times have you mindlessly unlocked your phone today? Ten? Twenty? Maybe even more?

If you’re nodding along (or secretly panicking)

welcome to the club. You might just be addicted to notifications—and don’t worry, you’re not alone.

But here’s the kicker: there’s actual tech behind why you can’t stop checking your phone. Yep, this isn’t just about bad habits. It’s engineered to hook you.

So, let’s see why that little red badge feels so irresistible.

Notifications: More Than Just Alerts

Notifications are often dismissed as “just reminders” or “simple pings.” But modern technology has made them strategic tools for attention capture.

How Tech Drives Your Attention:

Push Notification APIs: Apps like iOS and Android use APIs to push updates directly to your device, even when the app is closed.
Real-Time Data Triggers: Apps detect events that might matter to you — a new message, a like, a comment — and fire a notification.
Cross-Platform Syncing: Notifications follow you across devices, making it almost impossible to ignore them.

Every ping is backed by a data-driven decision: apps calculate when and what type of notification is most likely to get you to open them.

The Algorithms Behind the Ping

It’s not magic — it’s behavioral science plus machine learning.

Engagement Optimization Algorithms: Apps track your behavior (when you open notifications, how long you spend, what you ignore) and tweak what gets pushed.
Variable Reward Systems: Borrowed from psychology, these systems use unpredictability to maximize dopamine hits. Sometimes you get a super interesting alert, sometimes nothing — just enough to keep you checking.
Prioritization Logic: Notifications are ranked by likelihood of interaction. Your phone isn’t buzzing randomly — it’s buzzing strategically.

Essentially, your phone is running a tiny AI experiment on your attention 24/7.

Tech Tricks Apps Use to Hook You

Here’s what makes notifications practically irresistible:

Red Dots and Badges: Those tiny numbers on app icons? Engineered to trigger anxiety and compel action.
Push Sounds and Haptics: Different tones or vibrations are coded to grab attention — your brain starts associating them with “reward.”
Adaptive Notification Timing: Some apps learn your usage patterns and deliver notifications when you’re most likely to respond.
Infinite Scroll + Notifications: Social media combines endless content with frequent pings, creating a near-constant feedback loop.

It’s like the tech is saying:

“We know when you’re vulnerable — let’s get you to check this now.”

How Your Brain Interacts With Technology

Notifications are effective because your brain responds to predictable unpredictability:

Dopamine Loops: Each notification triggers a tiny dopamine spike. Your brain rewards the action of checking.
Intermittent Reinforcement: You don’t know if the next ping is exciting, boring, or irrelevant — and that uncertainty keeps you hooked.
Attention Hijacking: Even when you don’t want to check, your brain nudges you:

“Maybe it’s important…”

Tech engineers design notifications to exploit these patterns, making them psychologically irresistible.

How to Take Control of Tech Without Missing Out

If you want to stop being a slave to pings:

Smart Notification Settings: Only allow notifications from apps that truly matter.
Batching Notifications: Check emails, social media, and messages at designated times.
Focus & Do Not Disturb Modes: Let your device filter distractions during work or rest.
Mindful Interaction: Ask yourself before opening:

“Do I need to see this now?”

Remember — tech can be your tool, not your overlord.

Final Thoughts

Notifications are not a flaw — they’re engineered systems, powered by algorithms, APIs, and behavioral psychology. Your brain is responding exactly as designed.

Understanding the tech behind the buzz is the first step in regaining control.

Next time your phone pings, don’t just react — analyze, decide, and own your attention.

🎁 Bonus Tech Tool to Help You Regain Focus

One simple trick to break the reflex of opening apps is moving them around or replacing their usual spot on your home screen.

When your brain reaches for an app, it’s expecting it to be in the usual place. If it’s gone or in a different location, even for a second, your mind pauses and starts to notice:

“Wait… where did it go?”

That tiny moment of confusion is enough to interrupt the automatic habit loop, giving you a chance to decide consciously whether you really want to open it or not.

(OR)

Try this efficient way to overcome and Thank me later

One Sec App - Teaches you a sec can make a big impact

One especially helpful tool in the battle against addiction is One Sec — an app that interrupts your phone habits with a tiny pause, giving your brain a moment to decide if it’s really worth opening a distracting app.

Here’s what it does:

Delays access to distracting apps with a short pause or reflection screen
Encourages intentional use instead of reflexive scrolling
Helps reduce unconscious social media opens and doomscrolling behavior
Shows usage patterns so you can spot which apps pull your attention most

👉 Get it here:
https://play.google.com/store/apps/details?id=wtf.riedel.onesec

This app has been shown in research to reduce app usage significantly by creating friction that interrupts unconscious habits.

DOM in JavaScript — What Actually Happens When Your Code Runs

Kathirvel S — Tue, 17 Mar 2026 12:39:31 +0000

You’ve probably written DOM code like this before:

document.getElementById("title").textContent = "Hello World";

And it works.

But if I ask you:

“What exactly just happened inside the browser?”

Most people pause there.

Let’s fix that — step by step, no skipping, no guessing.

Start With This Simple HTML

<div id="app">
  <p id="text">Loading...</p>
  <button id="btn">Update</button>
</div>

Clean. Nothing fancy.

Now Add JavaScript

const text = document.getElementById("text");
const btn = document.getElementById("btn");

btn.addEventListener("click", () => {
  text.textContent = "Data loaded";
});

Looks simple.

But under the hood, a lot is happening.

Let’s slow it down.

Step 1: Browser Builds the DOM (Before Your JS Runs)

The moment the page loads:

Browser reads your HTML
Parses it line by line
Converts it into a DOM tree

Internally, it looks something like:

div#app
 ├── p#text ("Loading...")
 └── button#btn ("Update")

Important:

This structure lives in memory, not in your .html file.

Step 2: JavaScript Starts Running

Now your script executes:

const text = document.getElementById("text");

What happens internally?

The browser goes through the DOM tree
Looks for a node with id="text"
Finds the <p> element
Returns a reference to that node

So now:

text → points to <p> node in memory

Not a copy. The real node.

Step 3: Another Lookup Happens

const btn = document.getElementById("btn");

Same process:

btn → points to <button> node

At this point, your variables are directly connected to DOM nodes.

Step 4: Event Listener Gets Registered

btn.addEventListener("click", () => {
  text.textContent = "Data loaded";
});

Here’s what the browser does:

Attaches a “click listener” to the button node
Stores your callback function internally
Waits

Nothing changes visually yet.

Step 5: User Clicks the Button

Now the real flow begins.

When the user clicks:

Browser detects the click event
It checks the target node (button)
Finds your registered listener
Executes your function

Step 6: You Modify the DOM

text.textContent = "Data loaded";

Internally:

The <p> node’s text value is updated
The DOM tree is now different in memory

Before:

p → "Loading..."

After:

p → "Data loaded"

Step 7: Browser Re-Renders the Change

The browser notices:

“Something in the DOM changed.”

So it:

Updates only that part of the UI
Does not reload the page
Does not reprocess all HTML

Just a small, efficient update.

Now Let’s Push It a Bit Further

What if you didn’t just update text — but created something new?

btn.addEventListener("click", () => {
  const newMsg = document.createElement("p");
  newMsg.textContent = "New message added";

  document.getElementById("app").appendChild(newMsg);
});

Step-by-Step Again (Don’t Rush This)

1. `createElement`

A new <p> node is created
It exists only in memory
Not visible yet

2. `textContent`

Adds text inside that node
Still not visible

3. `appendChild`

The node is attached to div#app
Now it becomes part of the DOM tree

Before:

div
 ├── p
 └── button

After:

div
 ├── p
 ├── button
 └── p (new one)

4. Browser Updates the UI

Now the browser renders the new structure.

You see the new paragraph instantly.

The Pattern You Should Notice

Every DOM operation follows this pattern:

Find or create a node
Modify it
Attach it (if needed)
Browser updates the UI

That’s it.

One Thing You Should Stop Doing

Don’t think:

“I’m changing HTML”

You are not.

You are:

“Updating objects in the DOM tree”

The browser just reflects those updates visually.

Final Thought

If your UI changes, it’s because:

A DOM node changed
Or a new node was added/removed

There’s no hidden magic.

Just a structured tree in memory… and you controlling it.

Once you start thinking like this, DOM stops being confusing — and starts becoming predictable.

JavaScript Constructor Functions (Stop Copy-Pasting Objects)

Kathirvel S — Mon, 16 Mar 2026 13:47:08 +0000

Let me guess something.

You learned JavaScript objects like this:

const dog1 = {
  name: "Rocky",
  breed: "Labrador",
  bark() {
    console.log("Woof!");
  }
};

const dog2 = {
  name: "Max",
  breed: "Beagle",
  bark() {
    console.log("Woof!");
  }
};

Looks fine.

But here’s the uncomfortable question.

What happens when you need 50 dogs?

Are you going to copy-paste the same object again and again?

If that’s your plan…

We need to upgrade your JavaScript skills today 😄

This is exactly why constructor functions exist.

Let’s break it down step by step.

The Real Problem: Repeating Object Code

Imagine you're building a game with robots.

Each robot has:

name
energy level
ability to recharge

You could write:

const robot1 = {
  name: "RX-1",
  energy: 100,
  recharge() {
    this.energy += 20;
  }
};

const robot2 = {
  name: "RX-2",
  energy: 100,
  recharge() {
    this.energy += 20;
  }
};

Notice something?

The structure is identical.

You're just changing values.

That means we need a blueprint.

Step 1: Create a Constructor Function

A constructor function is basically a factory blueprint for objects.

function Robot(name, energy) {
  this.name = name;
  this.energy = energy;
}

Two important things here:

Function name starts with a capital letter
We use the this keyword

Why?

Because this represents the new object being created.

Step 2: Create Objects with `new`

Now we can create robots like this:

const robot1 = new Robot("RX-1", 100);
const robot2 = new Robot("RX-2", 80);
const robot3 = new Robot("RX-3", 50);

Boom

Now check the object:

console.log(robot1);

Output:

{
  name: "RX-1",
  energy: 100
}

Instead of writing objects manually, we generate them instantly.

Much better.

▶ Playground: Creating Multiple Objects

function Robot(name, energy) {
  this.name = name;
  this.energy = energy;
}

const robot1 = new Robot("RX-1", 100);
const robot2 = new Robot("RX-2", 80);
const robot3 = new Robot("RX-3", 50);

console.log(robot1);
console.log(robot2);
console.log(robot3);

Try pasting this in:

CodePen
JSFiddle
browser console

and watch how the objects are generated.

Wait… What Does `new` Actually Do?

Most developers use new like a magic spell without knowing what it does.

Let’s expose the magic.

When you run:

const robot1 = new Robot("RX-1", 100);

JavaScript secretly performs four steps.

1. Create an empty object

{}

2. Set `this` to the new object

Inside the constructor:

this.name = name

Actually becomes:

robot1.name = name

3. Connect the object to the prototype

This is where JavaScript inheritance begins.

4. Return the object

Final result:

{
  name: "RX-1",
  energy: 100
}

So the new keyword basically says:

“Create an object using this blueprint.”

Step 3: Adding Methods (The Beginner Mistake)

You might be tempted to do this:

function Robot(name, energy) {
  this.name = name;
  this.energy = energy;

  this.recharge = function () {
    this.energy += 20;
    console.log(this.name + " recharged!");
  };
}

Works perfectly.

const robot1 = new Robot("RX-1", 100);
robot1.recharge();

But there's a hidden problem.

Every time you create a robot:

const robot2 = new Robot("RX-2", 80);

JavaScript creates a brand new copy of the recharge function.

So if you create 100 robots → 100 functions in memory.

That’s inefficient.

Time for the real JavaScript power.

▶ Playground: The Memory Problem

function Robot(name, energy) {
  this.name = name;
  this.energy = energy;

  this.recharge = function () {
    this.energy += 20;
  };
}

const r1 = new Robot("RX-1", 100);
const r2 = new Robot("RX-2", 80);

console.log(r1.recharge === r2.recharge); // false

Output:

false

Each robot has its own function copy.

Step 4: Enter Prototype (The Real Superpower)

Instead of putting methods inside the constructor, we use prototype.

Prototype allows all objects to share the same method.

First define the constructor:

function Robot(name, energy) {
  this.name = name;
  this.energy = energy;
}

Now attach a method using prototype:

Robot.prototype.recharge = function () {
  this.energy += 20;
  console.log(this.name + " is recharging ⚡");
};

Now create robots:

const robot1 = new Robot("RX-1", 100);
const robot2 = new Robot("RX-2", 80);

Use the method:

robot1.recharge();
robot2.recharge();

Output:

RX-1 is recharging ⚡
RX-2 is recharging ⚡

Here’s the important part.

The recharge() function exists only once in memory, but every robot can use it.

This is prototype-based inheritance.

▶ Playground: Prototype Sharing

function Robot(name, energy) {
  this.name = name;
  this.energy = energy;
}

Robot.prototype.recharge = function () {
  this.energy += 20;
};

const r1 = new Robot("RX-1", 100);
const r2 = new Robot("RX-2", 80);

console.log(r1.recharge === r2.recharge); // true

Output:

true

Now both robots share the same function in memory.

Visualizing What Happens

When you access:

robot1.recharge()

JavaScript checks in this order:

1.Does robot1 have recharge? ❌
2.Check Robot.prototype ✅
3.Found it → execute function

This lookup chain is called the prototype chain.

And yes…

This is how JavaScript inheritance works internally.

Constructor Functions vs Classes

Modern JavaScript introduced classes.

Example:

class Robot {
  constructor(name, energy) {
    this.name = name;
    this.energy = energy;
  }

  recharge() {
    this.energy += 20;
  }
}

Looks nicer, right?

But here's the secret:

JavaScript classes are just syntactic sugar over constructor functions + prototypes.

Under the hood, it's still using prototype-based inheritance.

So if you understand constructor functions…

You understand JavaScript at a deeper level than many developers.

Quick Recap

Constructor functions help you:

✔ Create multiple objects easily
✔ Avoid repeating object structures
✔ Use prototypes to share methods
✔ Understand how JavaScript really works

Basic structure:

function Robot(name, energy) {
  this.name = name;
  this.energy = energy;
}

Robot.prototype.recharge = function () {
  this.energy += 20;
};

const robot1 = new Robot("RX-1", 100);

Final Thought

If you're skipping constructor functions because:

“Classes are easier.”

You're missing the core idea of JavaScript object creation.

And sooner or later…

That gap will catch up with you.

Learn the fundamentals now.

Future you will be grateful.

Most Developers Use URLs Daily — But Few Can Explain This

Kathirvel S — Sun, 15 Mar 2026 04:42:11 +0000

Ever looked at a URL and thought…

“What the heck are all these slashes, dots, and question marks doing here?”

You’re not alone.

Most developers use URLs every single day — copying them, sharing them, debugging them — but rarely stop to actually break them down and understand each piece.

Stop Copy-Pasting URLs. Start Understanding Them.

So today, let’s fix that.

Grab your coffee and let’s dissect a URL like developers do.

First, What Is a URL?

A URL (Uniform Resource Locator) is basically the address of something on the internet.

Just like your home address helps people find your house, a URL helps your browser find a specific resource on the web.

That resource could be:

a webpage
an image
a file
an API endpoint
a video
literally anything hosted online

Example URL:

https://www.example.com:443/products/item?id=25#reviews

Here’s the Real Example URL

https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=43s

You’ve definitely seen URLs like this before.

Looks scary?

Relax.

We’re going to slice it piece by piece

1.Protocol (How the Browser Talks to the Server)

https://

This tells the browser how to communicate with the website.

Common protocols you’ll see:

http → normal communication
https → secure encrypted communication 🔒
ftp → file transfers
mailto → send email

In our example:

https://

The S means Secure, which means the connection is encrypted.

That’s why browsers show the 🔒lock icon in the address bar.

Always a good sign.

2.Subdomain

www

This is a subdomain.

Websites use subdomains to organize different services.

Examples you might recognize:

blog.google.com
mail.google.com
api.github.com

Each one points to a different part of the same company’s infrastructure.

In our example:

www.youtube.com

www is the subdomain.

3.Domain Name

youtube

This is the main identity of the website.

It’s the name humans remember instead of typing an IP address like:

142.250.190.78

Imagine remembering that every time you want to watch a video.

Yeah… not happening.

So we use domain names instead.

4.Top-Level Domain (TLD)

.com

The TLD is the ending of the domain name.

Some common ones:

.com → commercial sites
.org → organizations
.edu → educational institutions
.net → networks
.io → popular with tech startups
.dev → developer focused

Country examples:

.in → India
.uk → United Kingdom
.jp → Japan

In our example:

youtube.com

Pretty standard.

5.Port (Usually Hidden)

:443

Ports are basically doors on a server.

Different services listen on different ports.

Common ones:

Port	Usage
80	HTTP
443	HTTPS
21	FTP

The funny thing?

Browsers hide them most of the time.

So this:

https://youtube.com

Actually means:

https://youtube.com:443

Sneaky, right?

6.Path (The Page You Want)

/watch

The path tells the server which specific page or resource you're requesting.

Think of it like folders on your computer.

Example structure:

website.com/blog/article

In our case:

youtube.com/watch

This tells YouTube:

“Hey, I want to open the video watching page.”

7.Query Parameters (Extra Data for the Server)

?v=dQw4w9WgXcQ

This part sends extra data to the server.

Structure:

?key=value

In our example:

?v=dQw4w9WgXcQ

v stands for video ID.

So the server reads this as:

“Load the video with ID dQw4w9WgXcQ.”

8.Multiple Query Parameters

Sometimes URLs send more than one piece of information.

That’s when you see the & symbol.

Example from our URL:

&t=43s

Now the full query becomes:

?v=dQw4w9WgXcQ&t=43s

Meaning:

v → which video
t → start time

So the video starts at 43 seconds.

Pretty neat.

9.Fragment (Jump to a Section)

#comments

This part doesn’t go to the server.

It’s handled by the browser.

Fragments are used to jump to a specific part of the page.

Example:

example.com/blog#comments

The browser scrolls directly to the comments section.

Super useful for long pages.

Full URL Breakdown

Let’s look at everything together:

https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=43s

Part	Meaning
https	protocol
www	subdomain
youtube	domain
.com	top level domain
:443	port
/watch	path
v=dQw4w9WgXcQ	video identifier
t=43s	start video at 43 seconds
#comments	fragment

Quick Fun Fact

When you press Enter after typing a URL, your browser secretly does a lot of work:

Checks if it already knows the IP address
If not, it asks DNS servers
Connects to the web server
Sends an HTTP request
Server sends back HTML, CSS, JS
Browser renders the page

All of that happens in milliseconds.

Pretty crazy when you think about it.

Final Thought

Next time you see a long messy URL…

Try breaking it down.

You’ll instantly understand:

what the website is doing
what data is being sent
how the page works behind the scenes

And once you start building APIs or debugging requests in DevTools…

This knowledge becomes super useful.

If you're learning web development, mastering small things like this will slowly make the entire web feel less like magic and more like engineering.

Happy coding !

🎁 Bonus: A Fun URL Experiment

Alright, quick challenge.

You just learned how URLs work… so let’s test it with a real one.

Take a look at this URL:

https://www.youtube.com/watch?v=C_ws3EX6DFA

Notice the query parameter:

?v=C_ws3EX6DFA

That’s the video ID YouTube uses to load a specific video.

Now here’s the fun part.

👇 Click it and see what happens.

https://www.youtube.com/watch?v=C_ws3EX6DFA

If you clicked it…

Congratulations.

You just got professionally Rickrolled by a URL tutorial.

And now you’ll probably never forget what a query parameter does.

Learning + internet culture = perfect combo.

Forem: Kathirvel S

I Built a Simple Todo App (and Learned More Than I Expected!)

What This Todo App Can Do

Where Everything Lives and Stays

Locking Things in Place

Rebuilding the Screen Every Time

Going Through Each Task

Showing the Task

Marking It Done

Toggling Completion

Editing a Task

Removing a Task

One Function Handling Two Jobs

Avoiding Empty Entries

Adding a New Task

Updating an Existing Task

Final Steps

A Small but Important Interaction

What This Project Really Teaches

Why Building Something Like This Matters

What Would You Add Next?

Final Thoughts

Why Is Google Called Google? The Surprising True Story Explained - (Sparked by a Last Notebook Page)

It All Started With a Massive Number

Why That Word?

The Twist That Changed Everything

Imagine If It Stayed “Googol”… 😬

Why the Name Actually Matters More Than You Think

A Quick Reality Check

The Real Lesson Behind the Name

Before You Scroll Away…

Stop Messing With APIs: How fetch() and .json() Actually Work

Look at This Code

Step 1: fetch() — Launching the Rocket

Step 2: res — The Sealed Capsule

Step 3: Why APIs Can’t Send JS Objects Directly

Step 4: .json() — Opening the Capsule

Step 5: Why .json() Returns a Promise

Step 6: Full Mission Flow

Step 7: Mental Model — Don’t Crash Your Mission

Conclusion — The NASA Analogy

JavaScript Promises: Transform Your Async Code from Messy to Clean

Step 1: The “Do Everything in Order” Phase (Synchronous JavaScript)

Step 2: “Let’s Not Make Users Wait” (Asynchronous JavaScript)

Step 3: “Okay, I Want Control” (Callbacks)

Step 4: The “Why Is This So Deep?” Moment (Callback Hell)

Step 5: A Cleaner Way (Promises)

Going Deeper: What a Promise Really Is

Small but Powerful Features of Promises

1. Chaining keeps things clean

2. Handling multiple async tasks

3. First result wins

Step 6: The Easiest Way (Async/Await)

Where Promises Are Really Used (And Why They Matter)

The Real Upgrade: From “It Works” to “It Feels Smooth”

Stop Misreading JavaScript: The Truth About Single Thread, Sync, and Async

The Truth: JavaScript is Single-Threaded

So Why Does JavaScript Feel Fast?

Let’s Play a Quick Game

What Just Happened?

Sync vs Async — Feel It, Don’t Memorize It

Synchronous (Sync)

Asynchronous (Async)

A More Real Example

Let’s Make It Personal

What’s Happening Behind the Scenes?

The Event Loop (In Human Terms)

Sync vs Async — Quick Feel Check

One Last Brain Teaser

The Big Takeaway

Before You Scroll Away

Final Thought

JavaScript Closures Explained Simply

First — don’t scroll

What do you think the output is?

Output:

Now here’s the real question

This is where closures hit you

Still not convinced? Let’s push you

Real scenario: Login system

Step 1: `fetch()` — Launching the Rocket

Step 2: `res` — The Sealed Capsule

Step 4: `.json()` — Opening the Capsule

Step 5: Why `.json()` Returns a Promise