DEV Community: Ebenezer

The Two Commands Every React Beginner Types Without Understanding

Ebenezer — Fri, 17 Apr 2026 12:39:37 +0000

Today was the day of tools. npm. npx. Vite. JSX. Fragment tags. Ports. My notion workspace filled up fast, and my head filled up even faster. By 2pm I had written things I understood in class but couldn't explain to anyone outside the room.

So I'm writing this the way I wish someone had written it for me before class — not the textbook version. The honest version. The "why does this even exist" version.

Here's what today actually covered, in plain words.

What you'll understand by the end:

Why npm and npx are two different tools that solve two different problems
What Vite is and why the folder it creates looks the way it does
Why JSX has those strange rules, and what Fragment tags are actually for

1. npm vs npx — The Kitchen and the Hotel Analogy

Sir gave us this analogy and I haven't been able to think of a better one since.

npm is like setting up a kitchen at home.

When you set up a kitchen, you go buy ingredients — oil, salt, rice, spices — and you store them in your cupboard. They stay there. You use them every day. Every project you cook uses those stored ingredients.

That's npm install. You download a package. It lives inside your project's node_modules folder. It's there permanently, ready every time you need it.

# This downloads React and saves it to your project
npm install react

npx is like ordering from a hotel.

You don't buy ingredients. You don't store anything. You call the hotel, they cook once, you eat, they leave. Nothing stays in your kitchen.

That's npx. It runs a package one time — downloads it temporarily, executes it, and then it's gone. You're not installing anything that lives in your project.

# Runs create-react-app once to set up your project — then disappears
npx create-react-app my-app

This is why you use npx to create a project but npm to run it. You only need the setup tool once. But you need React itself every single day.

The full name makes it obvious once you know it: npm is Node Package Manager — it manages. npx is Node Package Execution — it executes, one time, and leaves.

2. Vite — What It Is and Why the Folder Looks Like That

When you create a React project with Vite, you run:

npm create vite@latest my-app -- --template react

And suddenly there's a folder on your screen with files you didn't write. Most beginners stare at this and feel lost. I did.

Here's what Vite actually is: a build tool. Its job is to take your React code — which the browser cannot read directly — and convert it into regular HTML, CSS, and JavaScript that any browser understands. It also runs a local development server so you can see your work at localhost:5173 without putting anything on the internet.

Vite also bundles in third-party tools automatically. When you open the project folder, you'll see something like this:

my-app/
├── public/          ← static files (images, favicon)
├── src/
│   ├── App.jsx      ← your main component
│   ├── App.css      ← its styles
│   └── main.jsx     ← entry point — connects React to the browser
├── index.html       ← the one HTML file that runs everything
├── package.json     ← list of all your dependencies
└── vite.config.js   ← Vite's settings

The most important thing to notice: there's only one HTML file. That's not a mistake. That's the SPA (Single Page Application) design we talked about in yesterday's class — one file, JavaScript handles the rest.

main.jsx is where React connects to that HTML file:

// main.jsx — this is where React "wakes up" and takes over the page
import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App.jsx'

ReactDOM.createRoot(document.getElementById('root')).render(<App />)

That document.getElementById('root') is grabbing the single <div id="root"> in index.html. React injects everything inside that one div. The entire app — all your pages, components, buttons — lives inside that one div.

3. JSX — HTML Inside JavaScript, and Why It Has Rules

This is the part that confused me the most, and I think it confuses most beginners.

JSX stands for JavaScript XML. It lets you write what looks like HTML directly inside a JavaScript function.

// This is JSX — looks like HTML but it's inside JavaScript
function Greeting() {
  return (
    <h1>Hello,!</h1>
  );
}

But it's not HTML. The browser doesn't read JSX. Vite compiles it into plain JavaScript before the browser ever sees it. That <h1> becomes something like React.createElement('h1', null, 'Hello, Ebenezer!') under the hood.

Because it's JavaScript pretending to be HTML, it has strict rules that HTML doesn't have.

Rule 1: A component must return exactly one element.

A JavaScript function can only return one value. So your JSX can only have one root element wrapping everything else.

// ❌ This breaks — two root elements
function App() {
  return (
    <h1>Title</h1>
    <p>Subtitle</p>
  );
}

// ✅ This works — one root element wrapping both
function App() {
  return (
    <div>
      <h1>Title</h1>
      <p>Subtitle</p>
    </div>
  );
}

Rule 2: All tags must be closed.

In HTML, <br> and <img> are fine without closing. In JSX, they are not. XML rules apply — every tag must close itself.

// ❌ HTML habits that break in JSX
<br>
<img src="photo.jpg">
<input type="text">

// ✅ The JSX way — self-closing tags
<br />
<img src="photo.jpg" />
<input type="text" />

Also notice: in JSX you write className instead of class, because class is already a reserved word in JavaScript.

// ❌ class is a JS keyword — it conflicts
<div class="container">

// ✅ className is what JSX uses
<div className="container">

4. Fragment Tags — The Wrapper That Disappears

So Rule 1 says you need one root element. But what if you don't want an extra <div> cluttering your HTML just because React demanded it?

That's exactly what Fragment tags solve.

// ✅ Fragment — wraps without adding a real DOM element
function App() {
  return (
    <>
      <h1>Title</h1>
      <p>Subtitle</p>
    </>
  );
}

The <> and </> are short for <React.Fragment> and </React.Fragment>. They satisfy React's "return one element" rule without adding any actual HTML element to the page. When the browser renders this, it sees the h1 and p directly — no wrapper div anywhere.

This matters more than it sounds. When you're building lists or tables, unnecessary wrapper divs break layouts. Fragments let you keep your structure clean.

5. Servers and Ports — What's Actually Happening When You Run `npm run dev`

When you type npm run dev in your terminal, something happens that a lot of beginners don't think about.

A local server starts on your machine. That server is what you're accessing when you go to http://localhost:5173 in your browser. Your React app isn't on the internet — it's running on your own computer, and your browser is connecting to it like a client connecting to a remote website.

localhost means "this machine". 5173 is the port — the specific door on your machine where Vite's server is listening.

Your machine has thousands of ports. Port 80 is usually for regular websites. Port 3000 is what older React setups used. Vite chose 5173 as its default. If you run two projects at the same time, they'd need different ports — otherwise they'd clash trying to use the same door.

This is why sometimes your terminal shows Port 5173 is in use, trying 5174 instead. Another project already has that door open.

6. Hooks — The Teaser for Next Class

Sir mentioned Hooks at the very end and I could see half the class perk up, because we'd heard the word before.

Hooks are functions that give your components special powers. Things like remembering data, fetching from an API, or running code when the page loads.

The most common one is useState — it lets a component remember a value across re-renders:

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0); // start at 0

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

That's all I'll say for now. Hooks deserve their own post — and they're getting one. Today was setup day. Hooks are where React starts feeling genuinely powerful.

What You Learned Today

npm installs and stores packages permanently in your project — like stocking a kitchen
npx runs a package once and leaves — like ordering from a hotel
Vite is a build tool that sets up your project, runs a local dev server, and compiles your code so the browser understands it
JSX is HTML-inside-JavaScript — it has strict rules because it's actually XML, not HTML
Fragments (<>...</>) let you return multiple elements without adding useless divs to your page
localhost:5173 is your local server — your own machine serving your app to your browser during development

Over to you: Which part tripped you up the most — the npm vs npx difference, or the JSX rules? I'm still wrapping my head around the self-closing tag habit after years of writing HTML.

Drop it in the comments — I read every one. 👇

Stop Calling React a Framework. It's Embarrassing.

Ebenezer — Fri, 17 Apr 2026 04:49:52 +0000

My trainer asked one simple question yesterday that stopped me mid-note.

"Is that React is Library or Framework?."

Half the class looked confused. Someone asked, "What's the difference?" And instead of opening a textbook, sir said this:

"Think about your school library. Tamil books are in one shelf. English books in another. Maths in another. You walk in, pick the book you need, and walk out. The library doesn't tell you what to study. It just gives you what you ask for."

That's React. A library. You call it when you need it. It doesn't control your code — you control it.

That one sentence made everything click. Here's everything I understood from yesterday's class — explained the same way.

Here's what you'll learn:

Why React is a library and not a framework
What Functional Components actually are and why they exist
Why Facebook built React, and what problem it was solving

1. Library vs Framework — And Why People Always Confuse Them

A library is a collection of ready-made tools you can pick up and use whenever you want. You're in control.

A framework is like a blueprint. It tells you how to structure your entire project. You follow its rules — it controls the flow.

React is a library. When you write this:

// You are calling React — React isn't calling you
import React from 'react';

You decide when React runs. You call it. That's the library behaviour.

Angular, on the other hand, is a framework. It comes with routing, HTTP tools, form handling — everything bundled. You follow Angular's conventions. It calls your code.

React only does one thing: builds the UI. For everything else — routing, data fetching, state management — you bring your own tools. That's why frameworks like Next.js are built on top of React. React is the foundation; Next.js is the complete house.

2. The DOM Problem — Why Vanilla JS Gets Painful Fast

Before we understand why React exists, understand what it's solving.

Imagine you're building a navbar in plain JavaScript. Every time the user logs in, you have to manually find the element, change the text, maybe hide a button, show another one.

// Plain JS — you're doing DOM surgery by hand
document.getElementById('login-btn').style.display = 'none';
document.getElementById('user-name').textContent = 'Welcome, Ebenezer';
document.getElementById('logout-btn').style.display = 'block';

This works for 3 elements. But a real app has hundreds of elements changing based on data. You end up writing getElementById fifty times, losing track of which element you updated, and creating bugs that take hours to find.

React exists to automate this.

React automates the DOM. You describe what the UI should look like based on data, and React figures out what changed and updates only that part. You stop writing DOM instructions and start writing what the screen should show.

3. SPA — Why Facebook Needed to Reinvent How Websites Work

Do you remember early websites? Every time you clicked anything, the entire page would reload. White flash. Loading spinner. Annoying.

Facebook had a problem. They had millions of users with live notifications, chat messages, and news feed updates happening every second. If every "like" or new message triggered a full page reload, the experience would be unusable.

So Facebook needed a way to update parts of the page without reloading the whole thing. That idea became the Single Page Application (SPA).

In an SPA, the browser loads one HTML file once. After that, JavaScript handles everything — navigation, data updates, page transitions — without ever fully reloading. The URL changes, content changes, but the page never actually reloads.

Facebook built React in 2011, used it internally, and then open-sourced it in 2013.

Why open source? Because open source gets contributions from thousands of developers around the world — people finding bugs, building new features, writing better documentation. React became stronger because of the community. That's why it became the most popular UI library on the planet.

4. Functional Components — Stop Repeating Yourself

Imagine you have a navbar on every page. In plain HTML, you copy-paste the same navbar code on every single page. When you need to update one link, you update it on 20 files.

That's the problem components solve.

A Functional Component in React is a JavaScript function that returns a piece of UI. Write it once, use it everywhere.

// Navbar.jsx — write this once
function Navbar() {
  return (
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
      <a href="/contact">Contact</a>
    </nav>
  );
}

export default Navbar;

Now use it on any page:

// You just dropped a full navbar with one line
import Navbar from './Navbar';

function HomePage() {
  return (
    <div>
      <Navbar />
      <h1>Welcome</h1>
    </div>
  );
}

That <Navbar /> line brings in the entire navbar — with all its links, styling, and logic. Change it in one file, it changes everywhere.

This is the whole philosophy of React: build once, reuse everywhere. Every button, card, sidebar, footer — it's all a component you write once and stamp across your app.

5. CRA vs Vite — How You Actually Start a React Project

When you're starting a React project, you need a tool to set up all the boring configuration — the file structure, the build system, the development server. You don't write that by hand.

There are two popular ways:

Create React App (CRA) was the official way for years. One command and you had a full React project:

npx create-react-app my-app

But CRA got slow. The dev server took a long time to start. Builds were sluggish. The community started looking for something faster.

Vite is what most developers use now. It starts in milliseconds, hot-reloads instantly, and handles modern JavaScript much better.

npm create vite@latest my-app -- --template react

For learning, Vite is the better choice today. CRA is older and no longer actively maintained.

And none of this works without Node.js. Node lets you run JavaScript outside the browser and comes with npm — the package manager that installs React, Vite, and every other tool you need. When your trainer says "run npm install", Node is what's actually doing the work behind the scenes.

6. Checking the Latest React Version

Every few months, React releases updates. Features improve. Old patterns get replaced. As a developer, you should always know which version you're using.

Check your current React version inside any project:

# Run this in your project folder terminal
npm list react

Or open package.json in your project — you'll see the version number next to "react".

To always check the latest official release, visit react.dev. At the time of writing this post, React 19 is the latest stable version, which brought significant improvements to how forms and state work.

What You Learned Today

React is a JavaScript library — it builds the UI and nothing else. You call it, it doesn't call you
Functional Components exist to stop copy-pasting the same UI across files — write once, use everywhere
Facebook built React to create SPAs — apps that update content without reloading the whole page
React is open source because community contributions made it stronger than any one company could alone
Vite is the modern, fast way to start React projects — CRA is outdated
Everything runs through Node.js, which manages your packages and runs your dev environment

Over to you: What part of React confused you the most when you first heard about it? Was it the library vs framework thing, or something else?

Drop it in the comments — I read every single one. 👇

My Trainer Laid the Bricks. I Had to Build the House. Here Is What Happened.

Ebenezer — Tue, 07 Apr 2026 12:52:52 +0000

Vijayaragavan sir did not hand me a tutorial link this time.

He sat down, explained the logic of a to-do list in plain words, told me what it should do, and then stood up. That was it. Just a starter code. Just the idea — and the expectation that I would figure out the rest.

He laid the bricks. I had to complete the house.

I have heard that phrase before. It never meant anything to me until I was sitting alone with a blank JavaScript file, knowing what I wanted the app to do and having no clear idea how to make the page actually respond to me typing something and pressing a button.

Here is what we are going to cover:

How DOM manipulation is the thing nobody explains properly until you need it
How span tags turned a flat list item into something that actually works
How event listeners think — and why stopPropagation saved me from a bug I could not name

1. DOM Manipulation — When the Page Finally Talks Back

I had read the phrase "DOM manipulation" in at least a dozen tutorials before this project. Every one of them explained what the DOM is. None of them made me feel it.

DOM manipulation is the act of using JavaScript to reach into the HTML of a page and change it — add something, remove something, update something — while the user is looking at it. No refresh. No reload. The page just responds.

The moment it clicked for me was when I wrote this:

// Create a new list item and add it to the page when the user clicks "Add"
function newElement() {
    const input = document.getElementById("content");
    const inputVal = input.value.trim();

    if (inputVal === "") {
        alert("You must write some to-do");
        return;
    }

    const list = document.createElement("li");
    const myList = document.getElementById("myList");
    myList.appendChild(list);

    input.value = "";
}

What just happened: document.getElementById("content") reaches into the HTML and grabs the input field by its id. input.value.trim() reads whatever the user typed and removes any extra spaces around it. document.createElement("li") builds a brand new list item in memory — it does not exist on the page yet. myList.appendChild(list) actually puts it on the page. Then input.value = "" clears the input so the user can type the next task.

That sequence — grab, create, append, clear — is the backbone of almost every interactive thing you will build in JavaScript. I did not understand why tutorials kept repeating it until I wrote it myself and watched a new item appear on screen the moment I pressed Add.

It felt like the page was alive.

I also set the heading text only after the first task is added:

// Show "Today's Agenda" heading the moment the first task appears
const heading = document.getElementById("text");
heading.textContent = "Today's Agenda";

What just happened: textContent sets the visible text of any element. Before the user adds anything, the heading is empty. After the first task, it appears. One line. No conditions beyond the ones already in place.

2. Span Tags — The Hidden Architecture Inside Each Task

This is the part I did not anticipate needing to think about.

Each task on the list is not just text. It has three parts: a custom checkbox on the left, the task text in the middle, and a delete button on the right. A plain <li> element cannot hold all three independently unless you structure what is inside it carefully.

That is what span tags are for. A span is an inline container — it holds content inside a larger element without breaking the layout. On their own, spans are invisible. But give them a class, style them with CSS, and attach behavior to them, and they become the working parts of your UI.

// Build the internal structure of each task item using two span elements
const list = document.createElement("li");

const textSpan = document.createElement("span");
textSpan.classList.add("task-text");
textSpan.textContent = inputVal;

const spanClose = document.createElement("span");
spanClose.classList.add("close");
spanClose.innerHTML = "&times;";

list.appendChild(textSpan);
list.appendChild(spanClose);

What just happened: two spans are created in memory. The first gets a class of task-text and holds the user's input. The second gets a class of close and holds the times symbol, which renders as an X on screen. Both are appended to the list item in order — text first, delete button second. CSS does the rest: flex-layout lines them up, and the close span gets pushed to the right with margin-left: auto.

Before I understood this, I tried putting everything directly into the li as one piece of text. The delete button worked but toggling the checkbox would also trigger the delete. They were tangled. Separating them into spans gave each piece of the UI its own identity — its own class, its own event, its own behavior.

That separation is not just a coding pattern. It is a way of thinking about UI. Every visible thing on a page is its own element, and elements can be nested, layered, and controlled independently.

3. Event Listeners — And the One Line That Saved Everything

The toggle worked. The delete worked. But when I clicked delete, the task also toggled its checked state before disappearing. A flash of green, then gone. It looked broken.

I did not know what was causing it.

The problem is called event bubbling. When you click an element, the browser does not just fire the event on that element — it fires it on every parent element above it too, all the way up the tree. So clicking the close span was also triggering the click event on the li above it, which toggled the checked class before the delete had time to hide the item.

One line fixed it:

// Toggle checked state only when clicking the text — not the delete button
list.addEventListener("click", function (ev) {
    if (ev.target.tagName === "LI" || ev.target.classList.contains("task-text")) {
        list.classList.toggle("checked");
    }
});

spanClose.addEventListener("click", function (e) {
    e.stopPropagation();   // Stop the click from reaching the li above
    list.style.display = "none";
});

What just happened: the list click listener only toggles checked when the click target is the li itself or the task text span — not the close button. e.stopPropagation() on the close span tells the browser to stop passing this click event upward. It ends here. The li never hears about it.

stopPropagation is one of those things that sounds abstract until the exact bug it solves shows up in front of you. I had the bug first. Then I found the fix. Then it made sense. That order — problem, fix, understanding — is how most of JavaScript actually gets learned.

One more thing I want to be honest about: during this project, I learned that local storage exists. It is a browser feature that lets you save data between sessions — so tasks would survive a page refresh. I did not implement it in this version. Not because it was too hard, but because I wanted to make the core logic work cleanly first. Local storage is the next version. Skipping it was a decision, not a failure.

What This Project Actually Taught Me

You now know that a to-do list is not a list. It is a DOM tree that responds to user input in real time, where every visible element is a node you can create, modify, and remove with JavaScript. That sounds obvious in hindsight. Before this project, it was not.

My trainer gave me the logic. I had to translate it into working code. That gap — between understanding what something should do and knowing how to make it do it — is where the real learning happens. No tutorial closes that gap for you. You have to walk across it yourself.

You can see the finished app here: https://ebenezer6374-arch.github.io/ToDo/

If you want to see how the code is structured, the repository is on my GitHub. Everything from the HTML layout to the event logic is there — no frameworks, no libraries, just plain JavaScript doing the work.

Open a new file right now and try building this from scratch without looking at any code. Just hold the idea in your head — input, add button, list that grows, items that can be checked and deleted — and see how far you get before you need to look something up. You will be surprised.

What part of DOM manipulation confused you the most when you first ran into it? Drop it in the comments. I read every one, and I am probably one week ahead of where you are right now.

I Tried to Build a JavaScript Calculator . Here Is What Actually Happened.

Ebenezer — Sat, 04 Apr 2026 05:25:45 +0000

My Trainer, Mr.Vijayaragavan sir, gave me the task on a regular Tuesday. Just Basic instructions. No starter files. Just three words: build a calculator.

I nodded like I knew exactly what I was doing.

I did not.

I opened my code editor, stared at a blank HTML file for ten minutes, typed <div> and then deleted it. I did that three times. The blinking cursor felt personal. I had learned HTML. I had watched CSS tutorials. I had read about JavaScript. But the moment someone said "now go build something real," all of that evaporated.

Here is what we are going to cover:

How CSS Grid saved me when I had no idea how to lay out those buttons
The CSS styling tricks I picked up from forums that I had never seen in any tutorial
The JavaScript logic that makes a calculator actually work — and why it is more interesting than it looks

1. The Layout Problem I Did Not See Coming

The first thing I tried to do was lay out the buttons. A calculator has a grid — four columns, multiple rows. Simple enough on paper.

I tried using float. The buttons went everywhere. I tried inline-block. Better, but not right. I kept adjusting margins like I was trying to balance furniture in a room with no walls.

Then someone in a forum mentioned CSS Grid.

I had heard of it. The moment I read the docs properly, I felt that specific kind of frustration that comes right before something clicks — where you understand every word individually but not what they mean together.

CSS Grid is a layout system that lets you divide a container into rows and columns, and then place elements inside those divisions exactly where you want them. Think of it like drawing a table on a piece of paper and then putting things in specific cells.

Here is the part that actually solved my problem:

/* Grid layout that creates the 4-column calculator button structure */
#calbutton {
    display: grid;
    grid-template-columns: auto auto auto auto;
    padding: 10px;
}

What just happened: display: grid turns the container into a grid. grid-template-columns: auto auto auto auto tells the browser to create four equal columns. Every button I put inside that container automatically falls into the next available cell. No floats. No manual positioning.

But there was one more thing. A calculator's zero button spans two columns — it is wider than the others. I did not know how to handle that without breaking the whole grid.

The answer was one line of CSS I would never have found without a forum:

/* Makes the last button span 2 columns if it lands in the 3rd column position */
.button:last-child:nth-child(4n - 1) {
    grid-column: span 2;
}

What just happened: this selector targets the last button only when it falls in a specific position in the grid, then stretches it across two columns. It sounds complicated. Once I read what each part meant, it was almost elegant.

That one line saved me an hour of manual adjustments.

2. The CSS Styling I Picked Up Along the Way

I want to be honest about something. When I started, I thought CSS was just colors and fonts. I had no idea it could do what I ended up using it for.

The background of my calculator uses an animated gradient — a background that slowly shifts through a range of colors. I found this on a CSS tricks forum and modified it. I did not invent it. But I understood it by the time I was done.

/* Animated gradient background that cycles through multiple colors */
body {
    background: linear-gradient(-45deg, #ee7752, #e73c7e, #23a6d5, #23d5ab, green, yellow);
    background-size: 400% 400%;
    animation: gradient 15s ease-in-out infinite;
}

@keyframes gradient {
    0%   { background-position: 0% 50%; }
    50%  { background-position: 100% 50%; }
    100% { background-position: 0% 50%; }
}

What just happened: linear-gradient creates a gradient using six colors at a diagonal angle. background-size: 400% 400% makes the gradient much larger than the screen, so there is room for it to move. The @keyframes gradient block defines the animation — it shifts the background position slowly over 15 seconds, creating the illusion that the colors are flowing. infinite means it never stops.

The thing that surprised me most was how much CSS can feel like writing a small story. You define what something looks like, then you define how it changes over time. That felt creative in a way I did not expect from styling a webpage.

I also learned to respect border-radius. My buttons needed rounded corners to feel like a real calculator. One property, fifteen pixels, and suddenly the whole thing stopped looking like a school project.

3. The JavaScript Logic — Where Things Got Real

The layout was hard. The styling was interesting. But the JavaScript is where I actually understood what building something means.

A calculator needs to do four things: remember the first number you typed, remember the operator you chose, wait for you to type the second number, and then compute the result when you press equals. That is it. But translating that into code was not obvious to me.

Here is what I built:

// Core calculator logic — tracks operand1, operator, and operand2 across button clicks
var operand1 = 0;
var operand2 = null;
var operator = null;

function isOperator(value) {
    return value == "+" || value == "-" || value == "*" || value == "/";
}

for (var i = 0; i < buttons.length; i++) {
    buttons[i].addEventListener('click', function () {

        var value = this.getAttribute('data-value');
        var text = display.textContent.trim();

        if (isOperator(value) == true) {
            operator = value;
            operand1 = parseFloat(text);
            display.textContent = "";

        } else if (value == "=") {
            operand2 = parseFloat(text);
            var result = eval(operand1 + ' ' + operator + ' ' + operand2);
            if (result) {
                display.textContent = result;
                operand1 = result;
                operand2 = null;
                operator = null;
            }
        } else {
            display.textContent += value;
        }
    });
}

What just happened: every button on the calculator has a data-value attribute in the HTML. When you click a button, the event listener reads that value. If the value is an operator like + or -, it stores the current number on screen as operand1, saves the operator, and clears the display so you can type the second number. When you press =, it reads the second number as operand2, builds a math expression as a string, and uses eval() to calculate it.

The eval() function takes a string like "5 + 3" and evaluates it as if it were code. It is powerful. It is also something senior developers will tell you to use carefully in real production apps — because if someone passes malicious code as input, eval will run it. For a personal project and for learning the concept, it works perfectly.

What I kept getting wrong early on was the order of operations inside my head. I kept thinking: why does the display go blank when I press plus? Because I am clearing it to make room for the second number. Once I drew that flow out on paper — first number, operator, second number, equals — everything made sense.

The One Thing I Would Tell Someone Starting This

Do not wait until you feel ready to build something. I was not ready. I got stuck in real ways. I had to ask strangers on the internet for help and sit with the embarrassment of not knowing things I thought I should already know.

But the calculator I built by struggling through it taught me more than three weeks of following along with tutorials. Not because the struggle is romantic or necessary — but because real problems force you to actually think, not just copy.

You can see the finished calculator here: https://ebenezer6374-arch.github.io/Calculator/

It is not perfect. There are things I would change now that I know more. But it works. I built it. And a week ago I was staring at a blank file wondering how to start.

What This Actually Taught Me

You now know that a JavaScript calculator is not magic. It is three variables, a loop, a few conditions, and one grid. And knowing that should change how you look at the next "simple" thing someone asks you to build — because simple is almost never simple until you have been through it once.

Pick one project this week. Something small. A to-do list, a tip calculator, a random quote generator. Build it without a tutorial. Get stuck. Go to any soure you want . Come back.

What is the project you have been putting off because you did not feel ready yet? Drop it in the comments — I want to know what you are building.

One Worker, Zero Breaks: The Real Reason JavaScript Never Freezes

Ebenezer — Sat, 28 Mar 2026 05:50:45 +0000

Picture a busy restaurant kitchen. 🍽️

One chef. One stove. One order at a time.

That's JavaScript. One worker doing everything — reading your click, fetching your data, updating your screen. One at a time. No breaks. No shortcuts.

I used to wonder: "If JavaScript can only do one thing at a time, why doesn't my whole page freeze when it loads data from the internet?"

That question haunted me for weeks. Then I understood it — and everything about how JavaScript works finally made sense.

Here's exactly what we'll cover:

🧵 Why JavaScript is called "single-threaded" and what that actually means
⚔️ Single-threaded vs multi-threaded — the real difference
🔄 All the synchronous functions you're already using
⏳ All the asynchronous functions and why they exist
🧠 Why we call them "sync" and "async" in the first place

1. The One-Lane Highway — Why JavaScript Is Single-Threaded

A thread is like a worker's brain. One thread = one brain = one task at a time.

JavaScript has exactly one thread. One brain. One lane.

Imagine a highway with only one lane. Every car must wait for the car in front to move. No overtaking. No shortcuts. This is synchronous — one thing, then the next, in order.

// JavaScript executing line by line — one lane, no skipping
console.log("Car 1 moves");   // happens first
console.log("Car 2 moves");   // waits for Car 1
console.log("Car 3 moves");   // waits for Car 2
// Output: Car 1 moves → Car 2 moves → Car 3 moves

What just happened: JavaScript read line 1, finished it, then moved to line 2. No parallelism. Pure sequence.

That is the definition of single-threaded — one instruction, fully completed, before the next one begins.

2. Single-Threaded vs Multi-Threaded — The Real Difference

	Single-Threaded	Multi-Threaded
Workers	1	Many
Tasks at once	1 at a time	Many at once
Language	JavaScript	Java, Python, C++

Multi-threaded languages like Java can spin up multiple workers. One thread downloads the file. Another thread updates the UI. Another sends an email. All at the same time.

Imagine a restaurant with 10 chefs instead of 1. Orders come in and get handled simultaneously.

JavaScript sidesteps all of that by having just one chef. Simpler. Predictable. But there's a problem...

What happens when that one chef has to wait for something?

Like waiting for an order to arrive from the supplier. Do they just stand there doing nothing? 🧍

That's where synchronous vs asynchronous comes in.

3. Synchronous Functions — "Wait Your Turn"

Synchronous means: execute now, finish completely, then move on.

We call them "sync" because they happen in sync with the rest of the code — line by line, top to bottom, no jumps.

The Complete List of Sync Behaviours in JavaScript

// 1. Variable declarations — sync
let name = "Arjun"; // runs immediately

// 2. Math and operations — sync
let total = 10 + 20; // runs immediately, returns 30

// 3. console.log — sync
console.log("Hello"); // prints right now, blocks until done

// 4. Array methods — sync
let nums = [3, 1, 2];
nums.sort();           // sorts right now — .sort(), .map(), .filter(), .forEach()
nums.map(n => n * 2);  // transforms right now

// 5. String methods — sync
"hello".toUpperCase(); // returns "HELLO" immediately

// 6. JSON.parse and JSON.stringify — sync
let obj = JSON.parse('{"name":"Arjun"}'); // parses immediately

// 7. Object and Array operations — sync
Object.keys({ a: 1 }); // returns ["a"] immediately

// 8. Regular for loops — sync
for (let i = 0; i < 3; i++) {
  console.log(i); // 0, 1, 2 — each printed before next iteration
}

These all behave the same way: start → finish → next line. No waiting. No skipping. Completely predictable.

The danger? If one sync operation takes too long (like a heavy calculation), it blocks everything else. The page freezes. The user can't click anything. The chef is stuck chopping 1000 onions and the whole kitchen stops.

4. Asynchronous Functions — "Come Back When Ready"

Here's the problem that async solves.

Imagine fetching user data from a server. That might take 2 seconds. If JavaScript waited those 2 seconds doing nothing — blocking the thread — your entire website would freeze.

Nobody wants a frozen website.

Asynchronous means: start the task, hand it off, continue with other work, come back when the result is ready.

We call them "async" because they happen out of sync with the normal line-by-line flow — they start now but finish later.

The Complete List of Async Functions in JavaScript

// 1. setTimeout — runs a function after a delay
setTimeout(function() {
  console.log("I ran after 2 seconds"); // executes later, not right now
}, 2000);
console.log("I ran immediately"); // this prints FIRST

// 2. setInterval — runs repeatedly every N milliseconds
setInterval(function() {
  console.log("Tick every second");
}, 1000);




// 3. addEventListener — waits for a future event
document.getElementById("btn").addEventListener("click", function() {
  console.log("Button was clicked!"); // runs only when clicked — future event
});

What just happened in each case: JavaScript started the task, handed it to the browser to handle in the background, then immediately moved to the next line. When the browser finishes, it sends the result back.

5. The Secret Weapon — The Event Loop

So how does JavaScript juggle async tasks without multiple threads?

Meet the Event Loop — JavaScript's one-worker superpower.

“Want the full picture? I broke this down step-by-step in this blog 👉https://dev.to/buddingdeveloper/-understanding-the-event-loop-synchronous-vs-asynchronous-code-explained-for-beginners-2392

Think of it like this:

The chef (JavaScript) takes an order. If the dish needs 20 minutes to cook (async), they put it in the oven and take the next order. When the oven beeps (task is done), they come back and plate the dish.

The Event Loop constantly checks: "Is the current task done? Is there anything waiting?" If yes — it picks up the next thing. If an async task finishes — it brings the result back to the main thread.

console.log("1. Start");               // sync — runs first

setTimeout(() => {
  console.log("3. I was delayed");     // async — goes to the oven
}, 0); // Even with 0ms delay, async waits!

console.log("2. End");```

                 // sync — runs second

// Output:
// 1. Start
// 2. End
// 3. I was delayed   ← came back after sync code finished

Even with a 0 millisecond delay, the async code runs LAST. It waits for all sync code to finish first. That's the Event Loop in action.

6. Why We Name Them "Sync" and "Async"

It comes from music. 🎵

Synchronized musicians play together — in time, in order, perfectly lined up. Beat 1, then Beat 2, then Beat 3. That's sync code.

Asynchronous musicians play independently — one starts early, another comes in late, they don't wait for each other. That's async code.

JavaScript borrowed these words because they perfectly describe how code executes — either in perfect order (sync) or independently, whenever ready (async).

What You Learned Today

✅ JavaScript is single-threaded — one worker, one task at a time, just like a one-lane highway
✅ Multi-threaded languages run tasks in parallel but risk race conditions — JavaScript avoids all of that
✅ Sync functions run immediately and block until done — .map(), JSON.parse(), console.log()
✅ Async functions start now but finish later — setTimeout().
✅ The Event Loop is how one thread handles everything — the chef who uses an oven instead of standing still

Your next step: Open your browser console. Type console.log("1"), then setTimeout(() => console.log("2"), 0), then console.log("3"). Watch the order. That 60-second experiment will make the Event Loop click forever.

🔥 New here? Every single day we publish a fresh JavaScript or Java concept — plain English, real stories, code you can actually run. Follow to keep learning every day.

Over to you: What confused you more — that setTimeout with 0ms delay still runs last, or that async functions don't actually run in parallel? Drop it in the comments. 👇

The Secret Memory of JavaScript Functions That Nobody Talks About

Ebenezer — Fri, 27 Mar 2026 05:26:43 +0000

My Institute Trainer Mr.Vijayaragavan sir dropped this code on my screen during our training session:

function makeCounter() {
  let count = 0;
  return function () {
    count++;
    return count;
  };
}

const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

"How does count still exist?" I asked. "The makeCounter function already finished running."

He smiled. "That's the secret every JavaScript function carries."

I had no idea what he meant. But that moment changed how I write JavaScript forever.

Here's exactly what we'll cover:

🕰️ What JavaScript used to do before this concept existed (and why it was painful)
🧠 The "secret memory" that every function carries — explained simply
🎯 Beginner, Intermediate, and Pro level Q&A
🧩 An interactive quiz to test yourself at the end

1. Before the Secret — What JavaScript Developers Suffered Through

Before JavaScript had this feature, developers faced one massive problem: data didn't survive.

If you wanted a counter that remembered its value, your only option was a global variable.

// 😩 The old painful way — global variables everywhere
let count = 0; // This lives in the global scope — anyone can touch it

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

increment(); // 1
increment(); // 2

// But any other code could do this too:
count = 9999; // 💥 Oops. Anyone can break it.

Global variables are like leaving your diary on a park bench.

Anyone can read it. Anyone can write in it. It's chaos.

Developers needed a way to hide data inside a function but keep it alive across multiple calls.

That's exactly the problem this concept was built to solve.

2. The Secret Memory — What It Actually Is

Every function in JavaScript secretly remembers the environment it was born in.

Even after the parent function finishes, the inner function still holds a reference to the variables it had access to. This "backpack of memory" is what developers call a closure.

Think of it like this:

Imagine a chef 👨‍🍳 who leaves a restaurant but takes their personal spice kit with them.

The restaurant (the parent function) is gone. But the chef (the inner function)

still has their spices (the variables). They can cook anywhere.

// ✅ The clean, modern way — data is protected
function makeCounter() {
  let count = 0; // Hidden inside — nobody outside can touch this

  return function () {
    count++; // The inner function remembers "count" forever
    return count;
  };
}

const counter = makeCounter();
// makeCounter() finished running — but count is NOT gone!
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

What just happened: makeCounter returned an inner function. That inner function carried count in its memory. Even after makeCounter finished, count lives on — protected and private.

3. Real-World Uses You've Already Seen

This isn't just theory. You use this pattern every day without knowing it.

🛒 Shopping Cart Total

// Each user gets their own private cart total
function createCart() {
  let total = 0;

  return {
    addItem: function (price) {
      total += price;
    },
    getTotal: function () {
      return total;
    }
  };
}

const myCart = createCart();
myCart.addItem(299);  // Add ₹299 item
myCart.addItem(599);  // Add ₹599 item
console.log(myCart.getTotal()); // 898 — total is safe and private

⏱️ Button Click Counter

// Each button gets its OWN count — they don't share!
function makeButtonCounter(buttonName) {
  let clicks = 0;
  return function () {
    clicks++;
    console.log(buttonName + " clicked " + clicks + " times");
  };
}

const likeBtn = makeButtonCounter("Like");
const shareBtn = makeButtonCounter("Share");

likeBtn();  // "Like clicked 1 times"
likeBtn();  // "Like clicked 2 times"
shareBtn(); // "Share clicked 1 times" — completely separate!

Each call to makeButtonCounter creates a brand new, independent memory box.

4. Q&A — From Zero to Hero

🟢 Beginner Level

Q1: What problem does this concept solve?

It solves the global variable problem. Instead of storing shared data in the open where anyone can mess with it, you can lock data inside a function and expose only what you want.

Q2: Can a function access variables from its parent even after the parent is done running?

Yes — and that's the whole point. The inner function holds a live reference to the parent's variables, not a copy. The data stays alive as long as the inner function exists.

Q3: Is this something special you have to import?

No! Every function in JavaScript automatically has this ability. It's built into the language. You're using it whether you know it or not.

🟡 Intermediate Level

Q4: What's the difference between a copy and a reference here?

function outer() {
  let name = "Arjun";
  return function () {
    name = "Priya"; // Changes the ACTUAL variable, not a copy
    console.log(name);
  };
}

const fn = outer();
fn(); // "Priya" — the real "name" was modified

The inner function holds a live reference to name. Any change it makes is real. This is why two closures sharing the same variable can interfere with each other.

Q5: What happens with loops and this pattern?

This is the most common trap:

// 😱 Broken — all buttons say "3"
for (var i = 0; i < 3; i++) {
  setTimeout(function () {
    console.log(i); // Prints 3, 3, 3 — NOT 0, 1, 2
  }, 1000);
}

// ✅ Fixed with let — each iteration gets its own i
for (let i = 0; i < 3; i++) {
  setTimeout(function () {
    console.log(i); // Prints 0, 1, 2 ✅
  }, 1000);
}

var doesn't create a new scope per loop iteration. let does. Each iteration with let gets its own private memory box.

🔴 Pro Level

Q6: How does this relate to memory leaks?

Because the inner function holds a reference to the outer scope, that memory cannot be garbage collected as long as the inner function is alive.

function heavyOperation() {
  let bigData = new Array(1000000).fill("data"); // 1 million items in memory

  return function () {
    // Even if we only use one item, ALL of bigData stays in memory
    return bigData[0];
  };
}

const fn = heavyOperation();
// bigData is still in memory! It won't be freed until fn is garbage collected.

Fix: Set fn = null when you're done. This releases the reference and allows cleanup.

Q7: How do closures power the Module Pattern?

Before ES6 modules, developers used this pattern to create private state:

const BankAccount = (function () {
  let balance = 0; // Completely private — no outside access

  return {
    deposit: function (amount) { balance += amount; },
    withdraw: function (amount) { balance -= amount; },
    getBalance: function () { return balance; }
  };
})(); // IIFE — immediately invoked

BankAccount.deposit(1000);
BankAccount.withdraw(200);
console.log(BankAccount.getBalance()); // 800
console.log(BankAccount.balance);      // undefined — it's truly private!

This is the foundation of how libraries like jQuery were built.

5. Common Mistakes to Avoid

Mistake 1 — Thinking the variable is copied, not referenced.

Fix: Remember, the inner function holds a live wire to the outer variable.

Mistake 2 — Using var inside loops with async code.

Fix: Always use let in loops when you're creating functions inside.

Mistake 3 — Creating closures over huge data structures unnecessarily.

Fix: Extract only what you need before returning the inner function.

What You Learned Today

✅ Before this existed, developers used leaky global variables that anyone could break
✅ Every function secretly carries a memory backpack of its surrounding variables
✅ This powers real features — counters, carts, private modules, and more
✅ let vs var in loops changes everything — always use let
✅ Long-lived inner functions = long-lived memory — watch for leaks

Your next step: Open your browser console right now. Build a makeMultiplier(x) function that returns a function multiplying any number by x. Try makeMultiplier(5)(10) — it should return 50. That 5-minute exercise will make this click forever.

🧩 Test Yourself — Take the Quiz Below!

(Interactive quiz widget below — 5 questions from beginner to pro)

Over to you: Which level question surprised you the most — beginner, intermediate, or pro? Drop it in the comments. I read every single one. 👇

🔥 New here? We publish a new JavaScript or Java concept every single day — explained in plain English, with real stories and code you can actually use. Follow to never miss a post!

JavaScript Arrays vs Objects: Myths, Destructuring & Puzzles That Will Break Your Brain

Ebenezer — Thu, 12 Mar 2026 14:00:57 +0000

I remember staring at my screen at 11 PM, completely lost.

My mentor said "just store the data in an array."

My tutorial said "use an object for this."

I had no idea why one over the other.

I copy-pasted both. Neither made sense. I felt like a fraud.

If that's you right now — welcome. You're in the right place.

Here's exactly what we'll cover:

🧱 Why arrays were invented (the real story)
⚔️ Arrays vs Objects — what actually makes them different
💣 Myths that confuse 90% of beginners (and some seniors)
🔓 Destructuring — the superpower nobody explains simply
🧩 Tricky puzzles that even pro developers get wrong

1. Why Did Arrays Even Come Into Existence?

Imagine you're a teacher. You have 30 students. You need to store their names.

Without arrays, here's what your code would look like:

// 😱 The nightmare — storing 30 names without arrays
let student1 = "Arjun";
let student2 = "Priya";
let student3 = "Rahul";
// ... 27 more lines of this pain

Now imagine looping through them. Or sorting them. Or finding just one name.

Impossible.

Arrays were invented to solve exactly this — storing a list of related items under one name.

// ✅ The dream — one array holds everything
let students = ["Arjun", "Priya", "Rahul", "Sneha", "Vikram"];

console.log(students[0]); // "Arjun"
console.log(students.length); // 5

An array is like a row of numbered lockers 🔒.

Each locker has a number (starting from 0). You put things inside. You get them back by their number.

That's it. That's the origin story.

2. So What's an Object Then?

An object is what you reach for when your data has labels, not just a position.

Think of a student's profile:

// An array can store the values, but which is which?
let studentArray = ["Arjun", 21, "Computer Science", true];
// Wait... which index is the name? Which is the age? 🤔

// An object gives every value a name
let studentObject = {
  name: "Arjun",
  age: 21,
  department: "Computer Science",
  isEnrolled: true
};

console.log(studentObject.name); // "Arjun" — crystal clear

An object is like a contact card 📇.

Each field has a label (key) and a value. You don't need to remember positions.

The Simple Rule to Remember Forever

Use an array when order matters and items are similar.

Use an object when items are different and need labels.

Situation	Use
List of student names	Array
One student's profile	Object
Weekly temperatures	Array
Weather data (temp, humidity, city)	Object
Cart items in a store	Array of Objects 🔥

3. 💣 Myths That Are Lying to You

Myth #1: "Arrays and Objects are completely different things"

The truth? In JavaScript, arrays ARE objects.

// This will shock you
console.log(typeof []); // "object" 😱
console.log(typeof {}); // "object"

// Arrays are just special objects with numeric keys
let arr = ["a", "b", "c"];
// JavaScript secretly sees this as:
// { 0: "a", 1: "b", 2: "c", length: 3 }

An array is a object wearing a costume. It has numeric keys and a length property.

Myth #2: "Objects don't have order"

The truth? Modern JavaScript (ES2015+) actually maintains insertion order for string keys.

let obj = { banana: 1, apple: 2, cherry: 3 };
console.log(Object.keys(obj)); // ["banana", "apple", "cherry"] ✅ — order preserved!

But here's the twist — numeric keys get sorted automatically:

let tricky = { 2: "two", 1: "one", name: "test" };
console.log(Object.keys(tricky)); // ["1", "2", "name"] 😲 — numbers sorted first!

Myth #3: "You can't loop through an object"

The truth? You absolutely can — just differently.

let student = { name: "Priya", age: 20, city: "Chennai" };

// Loop through object keys
for (let key in student) {
  console.log(key + ": " + student[key]);
}
// name: Priya
// age: 20
// city: Chennai

Myth #4: "Arrays are faster than objects for everything"

The truth? Objects are actually faster for lookups by key.

// Finding "Rahul" in an array = check every item one by one 🐢
let names = ["Arjun", "Priya", "Rahul", "Sneha"];

// Finding "Rahul" in an object = instant lookup 🚀
let nameMap = { Arjun: true, Priya: true, Rahul: true, Sneha: true };
console.log(nameMap["Rahul"]); // true — found instantly

This is why objects are used in hash maps and lookup tables.

4. 🔓 Destructuring — The Superpower Nobody Explains Simply

Destructuring means pulling values out of arrays or objects into variables — in one clean line.

Object Destructuring

Without destructuring:

let student = { name: "Arjun", age: 21, city: "Mumbai" };

// Old way 😩 — three lines for three values
let name = student.name;
let age = student.age;
let city = student.city;

With destructuring:

// New way 🔥 — one line, same result
let { name, age, city } = student;

console.log(name); // "Arjun"
console.log(age);  // 21
console.log(city); // "Mumbai"

The variable names must match the keys. JavaScript matches them by name.

Rename While Destructuring

let { name: studentName, age: studentAge } = student;
// Now the variable is "studentName", not "name"
console.log(studentName); // "Arjun"

Default Values

let { name, score = 100 } = { name: "Priya" };
// "score" doesn't exist in object, so it uses the default
console.log(score); // 100

Array Destructuring

let colors = ["red", "green", "blue"];

// Pull them out by position
let [first, second, third] = colors;
console.log(first);  // "red"
console.log(second); // "green"

// Skip an item using a comma
let [primary, , tertiary] = colors;
console.log(primary);  // "red"
console.log(tertiary); // "blue" — green was skipped!

The Swap Trick (Destructuring party trick 🎉)

let a = 1, b = 2;

// Swap without a temp variable
[a, b] = [b, a];

console.log(a); // 2
console.log(b); // 1

5. 🧩 Tricky Puzzles — Beginners Will Struggle, Pros Will Double-Check

Puzzle 1: What does this print?

let arr = [1, 2, 3];
arr[10] = 99;

console.log(arr.length); // ❓
console.log(arr[5]);     // ❓

👉 Click to reveal answer

arr.length → 11
arr[5]     → undefined

JavaScript creates "holes" (empty slots) between index 3 and index 10.
The length becomes 11 (0 to 10), and any hole returns undefined.

Puzzle 2: Are these equal?

console.log([] == false);  // ❓
console.log([] === false); // ❓

👉 Click to reveal answer

[] == false  → true  😱
[] === false → false

== does type coercion. An empty array [] converts to "" which converts to 0, and false converts to 0. So 0 == 0 is true.

=== (strict equality) does NO conversion — different types, so false.

Puzzle 3: What's the output?

let obj = { a: 1 };
let copy = obj;
copy.a = 999;

console.log(obj.a); // ❓

👉 Click to reveal answer

obj.a → 999

Objects are stored by reference, not by value. copy and obj point to the same object in memory. Changing one changes both.

To truly copy: let copy = { ...obj };

Puzzle 4: This one hurts. What prints?

let user = { name: "Dev", scores: [10, 20, 30] };
let { name, scores: [first, ...rest] } = user;

console.log(name);  // ❓
console.log(first); // ❓
console.log(rest);  // ❓

👉 Click to reveal answer

name  → "Dev"
first → 10
rest  → [20, 30]

This is nested destructuring + rest operator combined.
scores: [first, ...rest] destructures the scores array inline.
...rest collects everything after first into a new array.

Puzzle 5: The boss-level one 🔥

const key = "name";
const obj = { [key]: "Arjun", age: 21 };

console.log(obj.name);  // ❓
console.log(obj.key);   // ❓
console.log(obj[key]);  // ❓

👉 Click to reveal answer

obj.name  → "Arjun"
obj.key   → undefined
obj[key]  → "Arjun"

[key] is a computed property name — it uses the value of key (which is "name") as the property name.

obj.key looks for a literal key called "key" — it doesn't exist.
obj[key] evaluates key → "name" → finds obj["name"] → "Arjun".

What You Learned Today

✅ Arrays were born to solve the "too many variables" problem — they're ordered lists
✅ Objects give your data labels — use them when things have names, not positions
✅ Arrays ARE objects in JavaScript — typeof [] === "object"
✅ Destructuring lets you unpack values in one elegant line
✅ Objects hold references — copying one means both change unless you spread it

Your next step: Open your browser console right now. Type out Puzzle 3 from scratch without peeking. Then fix it using the spread operator. That 2-minute exercise will make references click forever.

Over to you: Which puzzle broke your brain the most? Or do you have a trickier one? Drop it in the comments — I read every single one. 👇

The Object Reference Trap That Tricks Many Developers

Ebenezer — Wed, 11 Mar 2026 12:04:06 +0000

JavaScript Interview Puzzle #5

Over the past few days in this JavaScript Interview Puzzle series, we explored several small pieces of code that behave in surprising ways.

We looked at:

• The this keyword trap
• Type coercion surprises
• The JavaScript event loop

Each puzzle showed that JavaScript isn’t random.
It simply follows rules that we sometimes overlook.
Today’s puzzle looks even simpler.
But it reveals something extremely important about how JavaScript stores objects in memory.
Let’s see if this one tricks you.

The Puzzle

Look at the code below.

Before scrolling further, try to guess the output.

let a = { value: 10 };
let b = a;

b.value = 20;

console.log(a.value);

What do you think JavaScript will print?

Many beginners say:

Because they think a and b are separate objects.

But that is not what happens.

The real output is:

Wait.

Why did changing b also change a?

To understand this, we need to look at how JavaScript stores data in memory.

Let’s Pause for a Simple Story

Imagine you and your friend both have a map to a treasure chest.
You don’t each have your own chest.
You both have a map pointing to the same chest.
Now imagine your friend goes to the treasure chest and replaces the gold inside.
When you open the chest later…
You see the same change.
Why?
Because both maps pointed to the same location.
Objects in JavaScript behave exactly like that.

Understanding the Code

Let’s walk through the code step by step.

First we create an object.

let a = { value: 10 };

Now a points to an object in memory.

You can imagine it like this:

a → { value: 10 }

The Important Line

Now we write:

let b = a;

Many beginners think this creates a copy.

But it doesn’t.

Instead, JavaScript simply creates another reference to the same object.

Now both variables point to the same place.

a ──┐
    ├──> { value: 10 }
b ──┘

Changing the Object

Now we run this line.

b.value = 20;

This means:

“Go to the object that b points to and change its value.”

But remember — a also points to that same object.

So the object becomes:

{ value: 20 }

Now when we run:

console.log(a.value);

JavaScript prints:

Because a and b are both looking at the same object.

Primitive Values Work Differently

Numbers, strings, and booleans behave differently.

Example:

let x = 10;
let y = x;

y = 20;

console.log(x);

Output:

Why?

Because primitive values are copied, not referenced.

So x and y become completely separate.

Why Interviewers Love This Question

This puzzle tests whether you understand:

• JavaScript memory behavior
• Object references
• Primitive vs reference types

Many bugs in real applications happen because developers accidentally modify shared objects.

Understanding references helps prevent those mistakes.

A Slightly Trickier Variation

Try predicting the result of this code.

let user = { name: "Alex" };

let admin = user;

admin.name = "Sam";

console.log(user.name);

What do you think it prints?

Think about the treasure map story before running the code.

Final Thought

JavaScript often surprises developers not because it is complicated…

But because it behaves differently than we expect.

Objects are not copied automatically.

Instead, variables often act like maps pointing to the same location in memory.

Once you understand this rule, puzzles like this become easy to predict.

And more importantly, it helps you avoid subtle bugs in real projects.

Your Turn

Without running the code:

What do you think the variation example prints?

Write your guess in the comments before testing it.

Wrapping Up the Series

This puzzle also brings us to the end of this 4-day JavaScript Interview Puzzle series.
Over the last few days we explored:

• this context
• Type coercion
• The event loop
• Object references

If these puzzles made you pause and think, then they did their job.
JavaScript becomes much easier when we start understanding why the language behaves the way it does.
Thanks for reading and thinking through these puzzles with me.
We’ll continue exploring more JavaScript stories and concepts in future posts.

Until then, happy coding — and see you in the next story🖖.

Understanding the Event Loop, Synchronous vs Asynchronous Code (Explained for Beginners)

Ebenezer — Tue, 10 Mar 2026 13:28:25 +0000

JavaScript Interview Puzzle #3

Over the past few days in this JavaScript Interview Puzzle series, we explored some small pieces of code that behave in surprising ways.
Each puzzle looked simple.
But behind the scenes, JavaScript was following a set of rules that many beginners don't notice at first.

Today’s puzzle introduces one of the most important concepts in JavaScript:

• Synchronous code
• Asynchronous code
• Microtasks
• Macrotasks
• The Event Loop

These ideas power almost everything modern JavaScript does.
From loading websites…
to calling APIs…
to updating user interfaces.
Let’s explore them together through a small puzzle.

The Puzzle

Look at the code below carefully.

Before scrolling further, pause and try to predict the output.

console.log("Start");

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

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

console.log("End");

What do you think JavaScript will print?

Many beginners guess:

Start
Timeout
Promise
End

But the real output is:

Start
End
Promise
Timeout

At first glance, this might feel confusing.

To understand why this happens, we need to understand how JavaScript runs code.

Let’s Pause for a Simple Story

Imagine a small office with one worker.

This worker can only do one task at a time.

People keep giving the worker different tasks.

Some tasks are quick.

Some tasks take time.

Some tasks are extremely important and must be handled as soon as possible.

So the worker organizes the tasks into three categories:

Immediate work
Very important quick tasks
Tasks that can wait

JavaScript organizes work in a very similar way.

Synchronous Code (Immediate Work)

Synchronous code is the simplest type of code.

It runs line by line, exactly in the order it appears.

Example:

console.log("Hello");
console.log("World");

Output:

Hello
World

JavaScript executes the first line.

Then it executes the next line.

Then the next.

Nothing jumps ahead.

Nothing waits.

Everything happens in order.

This is called synchronous execution.

Asynchronous Code (Tasks That Take Time)

Some tasks take time.

For example:

• Calling a server
• Waiting for user input
• Loading data from a database
• Running a timer

If JavaScript waited for each task to finish, websites would feel slow.

So instead, JavaScript allows certain tasks to run asynchronously.

Example:

setTimeout(() => {
  console.log("Task finished");
}, 2000);

This means:

"Run this function after 2 seconds."

Instead of waiting, JavaScript continues executing other code.

This makes applications feel fast and responsive.

The Event Loop (The Task Manager)

JavaScript has something called the Event Loop.

Think of it as a manager that constantly asks:

"Is there any work waiting to be done?"

The event loop checks different queues and decides which task should run next.

To do that, JavaScript organizes tasks into two main queues:

• Microtasks
• Macrotasks

Microtasks (High Priority Tasks)

Microtasks are very important small tasks.

They always run before normal tasks.

Promises usually create microtasks.

Example:

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

Even though this runs asynchronously, JavaScript treats it with higher priority.

That’s why Promise callbacks run before many other asynchronous tasks.

Macrotasks (Normal Tasks)

Macrotasks are normal asynchronous tasks.

Examples include:

• setTimeout
• setInterval
• setImmediate

Example:

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

Even with a delay of 0, this task still waits in the macrotask queue.

JavaScript will only run it after finishing all microtasks.

Now Let’s Solve the Puzzle

Let’s go back to the code.

console.log("Start");

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

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

console.log("End");

Step 1 — Synchronous Code Runs First

JavaScript executes:

Start

Step 2 — setTimeout is Scheduled

JavaScript schedules the timer.

But it does not run yet.

Instead it goes into the macrotask queue.

Step 3 — Promise is Scheduled

The Promise callback is placed in the microtask queue.

Step 4 — Continue Synchronous Code

JavaScript runs the final synchronous line.

End

So the output becomes:

Start
End

Step 5 — Run Microtasks

The event loop now checks the microtask queue.

The Promise callback runs next.

Promise

Step 6 — Run Macrotasks

Finally JavaScript checks the macrotask queue.

Now the setTimeout callback runs.

Timeout

Final Output

So the final result becomes:

Start
End
Promise
Timeout

Once you understand the event loop, this result becomes predictable.

The Simple Rule to Remember

JavaScript executes tasks in this order:

Synchronous code
Microtasks (Promises)
Macrotasks (Timers, setTimeout)

This rule explains many asynchronous behaviors in JavaScript.

Why This Matters in Real Applications

Understanding the event loop helps developers work with:

• API requests
• UI updates
• React state updates
• Async/await
• Performance optimization

Many bugs in real applications happen because developers misunderstand how asynchronous tasks are scheduled.

Once you understand the event loop, these problems become much easier to solve.

A Small Challenge

Before running the code, try to predict the output.

console.log("A");

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

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

console.log("D");

Use the rule we learned.

Which one runs first?

Final Thought

JavaScript might seem unpredictable at times.

But most of the time it is simply following clear rules.

Once you understand synchronous execution, asynchronous tasks, microtasks, and macrotasks, the language becomes far easier to reason about.

And puzzles like this are a great way to build that understanding step by step.

Your Turn

Without running the code:

What do you think the challenge example prints?

Write your answer in the comments before testing it.

Tomorrow we will continue this JavaScript Interview Puzzle series with another small piece of code that reveals an interesting behavior of the language.

See you tomorrow.

The Type Coercion Puzzle That Makes JavaScript Look Weird

Ebenezer — Mon, 09 Mar 2026 06:45:04 +0000

Yesterday we looked at a small JavaScript puzzle involving the mysterious this keyword.

JavaScript Interview Puzzle #2

we explored small small pieces of code that looked innocent but behaved in surprising ways.
The goal of these puzzles is not to memorize tricks.The goal is to slowly understand how JavaScript actually thinks.
Today’s puzzle is one of the most famous JavaScript interview questions.
It looks so simple that many developers answer it confidently.
And then… JavaScript does something unexpected.
Let’s see if you can predict it.

The Puzzle

Look carefully at the following code.

Before scrolling down, try to guess the output.

console.log("5" + 3);
console.log("5" - 3);
console.log(true + true);
console.log(false + 5);

Take a moment.

What do you think JavaScript will print?

Many beginners assume the outputs should be something like this:

But that is only partially correct.

The real output is:

Wait.

Why did the first one become 53 instead of 8?
Did JavaScript forget how to do math?
Not exactly.
JavaScript is doing something called Type Coercion.

Let’s Pause for a Simple Story

Imagine you have two friends.

One friend speaks numbers.

The other friend speaks words.

Now imagine someone asks them to combine what they have.

Friend 1 says:

"I have the number 5."

Friend 2 says:

"I have the number 3."

If both are speaking numbers, the result is simple.

5 + 3 = 8

But imagine the first friend suddenly says:

"I have the word '5'."

Now the situation changes.

When someone mixes words and numbers, JavaScript decides:

"Okay… we are now speaking in words."

So instead of adding numbers, it joins them together like text.

"5" + 3

becomes

"53"

This is exactly what happens in our puzzle.

Understanding the First Line

Let’s examine this line.

console.log("5" + 3);

Notice something important.

The 5 is inside quotes.

"5"

That means it is not a number anymore.

It is a string (text).

When JavaScript sees the + operator with a string, it assumes we want string concatenation.

So instead of doing math, it combines the text.

"5" + 3 → "53"

The Second Line

Now look at this one.

console.log("5" - 3);

Why didn’t this become "53"?

Why did it become 2?

Because the minus operator cannot work with text.

Subtraction only makes sense with numbers.

So JavaScript automatically converts the string "5" into a number.

Then it performs the math.

5 - 3 = 2

The Third Line

Now let’s look at something interesting.

console.log(true + true);

What should this be?

JavaScript converts boolean values to numbers when doing math.

true = 1
false = 0

So the calculation becomes:

1 + 1 = 2

That is why the output is:

The Fourth Line

Finally, we have this.

console.log(false + 5);

Again JavaScript converts the boolean value.

false = 0

Now the calculation becomes:

0 + 5 = 5

So the output is:

Why JavaScript Does This

JavaScript was designed to be flexible.
Sometimes that flexibility creates confusing behavior.
When different types appear together, JavaScript tries to automatically convert them so the operation can continue.

This automatic conversion is called:

Type Coercion

It is one of the most important concepts in JavaScript.

Why Interviewers Love This Question

This puzzle tests whether developers understand:

• JavaScript data types
• Type coercion rules
• Operator behavior

Many developers memorize syntax.

But interviewers want to see whether you understand how the language behaves internally.

Questions like this reveal that understanding very quickly.

A Slightly Trickier Example

Try predicting the result of this code.

console.log("10" + 2 + 3);
console.log("10" - 2 - 3);

Think about it before running the code.

Does JavaScript perform math?
Or does it combine text?
Understanding this puzzle will make the answer obvious.

A Simple Rule to Remember

When working with the + operator in JavaScript:

If one value is a string, JavaScript usually switches to string mode.

But operators like -, *, and / force JavaScript to use numbers.

That small rule explains most type coercion behavior.

Final Thought

JavaScript is often described as a language full of surprises.

But most of those surprises disappear once you understand its rules.

Type coercion is one of those rules.

Once you recognize how JavaScript converts values automatically, puzzles like this become easy to predict.

And more importantly, you avoid bugs in real projects.

Your Turn

Without running the code:

What do you think this prints?

console.log("10" + 2 + 3);
console.log("10" - 2 - 3);

Write your guess in the comments before testing it.

Tomorrow we will explore Puzzle #3 in this JavaScript interview puzzle series — another tiny piece of code that behaves in a very surprising way.

See you tomorrow.

JavaScript Interview Traps That Destroy 90% of Candidates

Ebenezer — Sat, 07 Mar 2026 06:58:55 +0000

JavaScript Interview Puzzle #1

The `this` Keyword Trap That Confuses Even Experienced Developers

Most developers think they understand JavaScript.And to be fair — most of the time they do.But every now and then, JavaScript throws a small puzzle that quietly exposes a gap in our understanding.

Today’s puzzle is one of those.It looks harmless.It looks simple.But it has confused thousands of developers during interviews.

Let’s see if it tricks you too.

The Puzzle

Look at the code below carefully.

What do you think it will print?

const user = {
  name: "Ebenezer",
  greet: function() {
    console.log(this.name);
  }
};

const greetFunc = user.greet;
greetFunc();

Take a moment.
Don't rush to the answer.
What do you think the output will be?

Most people say:

Ebenezer

But that is not what JavaScript prints.

The actual output is:

undefined

Wait.
Why?
The object clearly has a name.
So why did JavaScript forget it?
To understand this puzzle, we need to talk about one of JavaScript’s most misunderstood ideas:

The this keyword.

Let’s Understand This With a Tiny Story

Let’s imagine something simple.You have a robot.And that robot belongs to you.You tell the robot:
“Whenever someone asks who you belong to, say my name.”
So the robot has instructions like this:

Robot:
If someone asks → say owner name

Now imagine something interesting happens.Someone removes the robot from your house.The robot is standing alone somewhere else.
Now someone asks the robot:

“Who is your owner?”The robot looks around.It doesn't see you.
So it says:
“I don’t know.”

That is exactly what happens in our JavaScript puzzle.

Understanding the Code Slowly

Let’s look at the first part.

const user = {
  name: "Ebenezer",
  greet: function() {
    console.log(this.name);
  }
};

Here we created an object called user.
Inside the object we have:

name → "Ebenezer"
greet → a function

The important part is this line:

console.log(this.name)

Here this refers to the object that owns the function.

So if we run this:

user.greet();

JavaScript understands that the function belongs to user.

So this becomes:

this = user

Which means:

this.name = "Ebenezer"

So it prints:

Ebenezer

So far everything makes sense.

Now Comes the Trap

Look at this line again.

const greetFunc = user.greet;

What did we just do?
We took the function out of the object.
It’s no longer attached to user.
Now greetFunc is just a normal standalone function.

When we call it:

greetFunc();

JavaScript asks:

“Who owns this function?”
But there is no object calling it anymore.
So this becomes:

undefined

Which means:

this.name → undefined

And that is exactly what gets printed.

The Rule That Saves You

Here is a simple rule to remember.

this depends on how a function is called, not where it was written.

That sentence is one of the most important lessons in JavaScript.
Let’s repeat it again.

this depends on how the function is called.

Not where it was defined.

How Interviews Use This Question

Interviewers love this puzzle.Not because it is complicated.But because it tests whether you understand:

• JavaScript function context
• Object methods
• The this keyword

Many developers memorize syntax.
But interviews test mental models.And this puzzle reveals whether someone truly understands JavaScript behavior.

The Correct Way to Preserve `this`

If you want the function to always remember the object, you can use .bind().

Example:

const greetFunc = user.greet.bind(user);
greetFunc();

Now the output becomes:

Ebenezer

Because we permanently told the function:

“Your this should always be user.”

Why This Matters in Real Applications

This concept appears everywhere in JavaScript.
For example:

• Event listeners
• React components
• Callbacks
• Timers
• API handlers

Many bugs happen because developers lose the correct this context.
Understanding this puzzle helps you avoid those mistakes.

Try This Variation

Before you leave, try solving this.
What will this print?

const person = {
  name: "Alex",
  sayHello() {
    console.log(this.name);
  }
};

setTimeout(person.sayHello, 1000);

Take a guess before running it.You might be surprised again.

Final Thought

JavaScript is not just about writing code.
It’s about understanding how the language thinks.
Small puzzles like this reveal the hidden rules behind the language.
And once you see them, JavaScript suddenly feels much clearer.

Your Turn

What do you think the second example prints?
Write your answer in the comments before testing it.
Tomorrow we’ll look at another JavaScript interview puzzle that tricks even experienced developers.

See you in Puzzle #2.

Problem Solving Series — Day 1 The String Problem That Taught Me About Sets in JavaScript

Ebenezer — Fri, 06 Mar 2026 02:07:59 +0000

Strings • Sets • Sliding Window • Beginner Developer Journey

I realized that learning syntax alone doesn’t make someone a programmer — real programming is about thinking, logic, and solving problems.
That’s why I’m starting this Problem Solving Series, inspired by a conversation with my friend Bala yesterday (you can read that story here:https://dev.to/buddingdeveloper/i-blinked-when-my-friend-asked-this-question-39k4

Problem Solving Series

Every day I will pick one problem, try to understand it, think about the logic, and share the learning.Some problems will be easy.Some will be confusing.Some might break my brain.
But the goal is simple:
Learn to think like a programmer, not just write code.
And today is Day 1.

Today’s Problem

The problem looks simple at first glance.
You are given a string.
Your task is to find the longest substring that contains no repeating characters.

Example string:

pwwkew

We need to find the longest continuous group of characters where no character repeats.

Possible substrings:

pw wk wke kew

The longest one is:
wke
Length:
3

So the output should tell us:
the length
and the actual substring

Thinking Before Coding

Instead of jumping directly into code, I tried to think about the logic first.
Imagine reading the string from left to right.
We keep a window of characters that are currently unique.

Example:

p → unique pw → still unique

Then suddenly we see:
pww
Now a repetition appears.So the window is no longer valid.
We need to move the starting point forward until the repetition disappears.This idea is known as the Sliding Window Technique.
Many real interview problems use this pattern.

Why I Used a Set

While solving the problem I needed a quick way to answer this question:
“Have I already seen this character in my current window?”
JavaScript has a very nice data structure for this.
It’s called a Set.
A Set is a collection that stores only unique values.

For example:

const seen = new Set()

seen.add("a")
seen.add("b")
seen.add("a")

console.log(seen)

Output:

Set { 'a', 'b' }

Even though "a" was added twice, the Set keeps only one copy.
This makes it perfect for tracking unique characters in a substring.
The Set gives us three very useful operations:

Extracting the Longest Substring

At the end of the algorithm we know two important things:
where the longest substring startshow long it isNow we need to cut that part from the string.
JavaScript gives us a simple method called:

substring()

Example:

let word = "javascript"

console.log(word.substring(0,4))

Output:

java

It extracts characters starting from index 0 up to 4 (not including 4).
In our solution we use this idea like this:

str.substring(startIndex, startIndex + length)

This gives us the exact longest substring.

JavaScript Solution

function longestUniqueSubstring(str) {
  let start = 0
  let maxLength = 0
  let maxStart = 0

  const seen = new Set()

  for (let end = 0; end < str.length; end++) {

    while (seen.has(str[end])) {
      seen.delete(str[start])
      start++
    }

    seen.add(str[end])

    if (end - start + 1 > maxLength) {
      maxLength = end - start + 1
      maxStart = start
    }

  }

  return {
    length: maxLength,
    substring: str.substring(maxStart, maxStart + maxLength)
  }
}

Why This Solution Is Efficient

This algorithm scans the string only once.
So the time complexity (TBD)is:
O(n)
Which means it scales well even for long strings.
Instead of checking every possible substring (which would be slow), we expand and shrink a window dynamically.
That’s the power of the sliding window technique.

What I Learned Today

Day 1 of this series already taught me a few important things.
Programming problems are not about writing complicated code. They are about understanding patterns and logic.
Today’s problem helped me learn about:

The Sliding Window technique
How Sets store unique values
How to extract parts of strings using substring()

And most importantly, it reminded me that becoming a developer is not about rushing through tutorials.
It’s about thinking, struggling, and gradually improving.

That’s it for Problem Solving — Day 1
If you solved this problem in a different way, I’d love to see your approach.
Share it in the comments — I’m always excited to learn new ways of thinking.
See you tomorrow with the next problem… and hopefully a slightly smarter brain. 😄

DEV Community: Ebenezer

The Two Commands Every React Beginner Types Without Understanding

1. npm vs npx — The Kitchen and the Hotel Analogy

2. Vite — What It Is and Why the Folder Looks Like That

3. JSX — HTML Inside JavaScript, and Why It Has Rules

4. Fragment Tags — The Wrapper That Disappears

5. Servers and Ports — What's Actually Happening When You Run npm run dev

6. Hooks — The Teaser for Next Class

What You Learned Today

Stop Calling React a Framework. It's Embarrassing.

1. Library vs Framework — And Why People Always Confuse Them

2. The DOM Problem — Why Vanilla JS Gets Painful Fast

3. SPA — Why Facebook Needed to Reinvent How Websites Work

4. Functional Components — Stop Repeating Yourself

5. CRA vs Vite — How You Actually Start a React Project

6. Checking the Latest React Version

What You Learned Today

My Trainer Laid the Bricks. I Had to Build the House. Here Is What Happened.

1. DOM Manipulation — When the Page Finally Talks Back

2. Span Tags — The Hidden Architecture Inside Each Task

3. Event Listeners — And the One Line That Saved Everything

What This Project Actually Taught Me

I Tried to Build a JavaScript Calculator . Here Is What Actually Happened.

1. The Layout Problem I Did Not See Coming

2. The CSS Styling I Picked Up Along the Way

3. The JavaScript Logic — Where Things Got Real

The One Thing I Would Tell Someone Starting This

What This Actually Taught Me

One Worker, Zero Breaks: The Real Reason JavaScript Never Freezes

1. The One-Lane Highway — Why JavaScript Is Single-Threaded

2. Single-Threaded vs Multi-Threaded — The Real Difference

3. Synchronous Functions — "Wait Your Turn"

The Complete List of Sync Behaviours in JavaScript

4. Asynchronous Functions — "Come Back When Ready"

The Complete List of Async Functions in JavaScript

5. The Secret Weapon — The Event Loop

6. Why We Name Them "Sync" and "Async"

What You Learned Today

The Secret Memory of JavaScript Functions That Nobody Talks About

1. Before the Secret — What JavaScript Developers Suffered Through

2. The Secret Memory — What It Actually Is

3. Real-World Uses You've Already Seen

🛒 Shopping Cart Total

⏱️ Button Click Counter

4. Q&A — From Zero to Hero

🟢 Beginner Level

🟡 Intermediate Level

🔴 Pro Level

5. Common Mistakes to Avoid

What You Learned Today

🧩 Test Yourself — Take the Quiz Below!

JavaScript Arrays vs Objects: Myths, Destructuring & Puzzles That Will Break Your Brain

1. Why Did Arrays Even Come Into Existence?

2. So What's an Object Then?

The Simple Rule to Remember Forever

3. 💣 Myths That Are Lying to You

Myth #1: "Arrays and Objects are completely different things"

Myth #2: "Objects don't have order"

Myth #3: "You can't loop through an object"

Myth #4: "Arrays are faster than objects for everything"

4. 🔓 Destructuring — The Superpower Nobody Explains Simply

Object Destructuring

Rename While Destructuring

Default Values

Array Destructuring

The Swap Trick (Destructuring party trick 🎉)

5. 🧩 Tricky Puzzles — Beginners Will Struggle, Pros Will Double-Check

Puzzle 1: What does this print?

Puzzle 2: Are these equal?

Puzzle 3: What's the output?

Puzzle 4: This one hurts. What prints?

Puzzle 5: The boss-level one 🔥

What You Learned Today

The Object Reference Trap That Tricks Many Developers

JavaScript Interview Puzzle #5

The Puzzle

Let’s Pause for a Simple Story

Understanding the Code

The Important Line

Changing the Object

5. Servers and Ports — What's Actually Happening When You Run `npm run dev`

The `this` Keyword Trap That Confuses Even Experienced Developers

The Correct Way to Preserve `this`