What The Heck Is A Component?
Learn what React components are and why they revolutionized frontend development. A beginner-friendly guide explaining component-based architecture, JSX syntax, and how to think in components. Perfect for developers transitioning from HTML/CSS/JavaScript to React.
The Beginning: A World of Index.html
I still remember my first website. It was 2016, and I had just discovered that you could right-click on any webpage and select “View Page Source.” Mind. Blown.
<!DOCTYPE html>
<html>
<head>
<title>My First Website</title>
</head>
<body>
<h1>Welcome to My Website!</h1>
<p>This is so cool!</p>
</body>
</html>
That was it. That was the whole thing. And I was absolutely thrilled. I spent hours copying snippets from tutorials, changing colors in CSS, and breaking things in JavaScript. It was beautiful chaos.
The Problem Nobody Told Me About
Fast forward a few months. My “website” had grown. And by “grown,” I mean it had become an unmanageable monster of copy-pasted HTML.
Want to add a navigation bar? Copy it to every single page. Want to change a link? Better remember to update it in 15 different files. Want to maintain your sanity? Too late for that.
Here’s what my file structure looked like:
my-website/
├── index.html
├── about.html
├── contact.html
├── projects.html
├── blog.html
├── styles.css (1500 lines of chaos)
└── script.js (please don't look at this)
The navigation alone was duplicated across every file. One typo fix meant editing five files. I was basically a human copy-paste machine.
Enter: The Word That Changed Everything
I kept seeing this word everywhere: Component.
React components. Vue components. Web components. Angular components. Component this, component that. But what the heck was a component?
Every tutorial assumed I already knew. Every documentation started with “Let’s create a simple component” without explaining what that actually meant.
The Lightbulb Moment
One day, after countless YouTube videos and documentation rabbit holes, it finally clicked.
A component is just a reusable piece of UI.
That’s it. That’s the tweet.
Think about it like LEGO blocks. Instead of building your entire spaceship from one solid piece of plastic, you use smaller, standardized blocks that snap together. Each block is a component.
// This is a component. It's just a function that returns some UI.
function NavigationBar() {
return (
<nav>
<a href="/">Home</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>
);
}
Now instead of copying that navigation HTML to every page, I could just write:
<NavigationBar />
ONE change. ONE place. EVERYWHERE it’s used gets updated automatically.
But Why Does This Matter?
Let me paint you a picture of the before and after:
Before (Raw HTML)
- Change the nav? Edit 10 files.
- Add a new page? Copy the entire header, footer, and navigation.
- Find a bug? Good luck finding all the places you need to fix it.
After (Components)
- Change the nav? Edit 1 file.
- Add a new page? Import the components you need.
- Find a bug? Fix it once, done.
It’s not just about less typing. It’s about maintainability. It’s about sanity. It’s about being able to make changes without fear.
The Weird Syntax Thing (JSX)
Now, I’ll be honest. When I first saw JSX, I thought someone had made a terrible mistake:
function Button({ text, onClick }) {
return (
<button onClick={onClick} className="cool-button">
{text}
</button>
);
}
“Is that… HTML inside JavaScript? Is that legal? Should I call someone?”
But here’s the thing: JSX is just JavaScript pretending to be HTML. It gets transformed into regular JavaScript function calls. It’s syntactic sugar that makes writing UI code feel more natural.
Once I stopped fighting it and embraced the weird, everything became easier.
Components Are Everywhere Now
What started as a React thing has become the standard way of building web applications:
- React - The OG component library
- Vue - Components with a gentler learning curve
- Svelte - Components that compile away
- Web Components - Native browser components
- Astro - Components that ship zero JavaScript by default
The mental model is the same everywhere: break your UI into small, reusable pieces.
What I Wish I’d Known Earlier
-
You don’t need a framework to think in components. Start by identifying repeated patterns in your HTML. That’s a component waiting to happen.
-
Components can contain other components. It’s turtles all the way down.
-
Props are just function arguments. If you understand functions, you understand props.
-
State is just data that can change. When state changes, the component re-renders with the new data.
-
It’s okay to be confused. Everyone was confused at first. The documentation writers just forgot what it was like to not know.
The Journey Continues
Understanding components was just the beginning. There’s still state management, hooks, server components, hydration, and a hundred other concepts to wrap my head around.
But that first “aha!” moment—realizing that a component is just a reusable piece of UI—that was the foundation everything else built upon.
If you’re where I was in 2019, staring at React tutorials in complete confusion, I hope this helps. A component isn’t magic. It’s just a function that returns some UI. That’s it.
Now go build something cool.
P.S. - If you’re still reading raw HTML files with copy-pasted navigation bars, I see you. I was you. There’s no shame in it. But trust me, the component life is so much better.
Saurav Sitaula
Software Architect • Nepal