What is React? — ReactJS Series Part 1

Introduction

If you're starting your journey into modern frontend development, React is one of the first names you'll hear. Created by Facebook (now Meta) in 2013, React has become the most widely adopted JavaScript library for building user interfaces.

But what exactly is React? Why do developers choose it over plain HTML and JavaScript? And what problems does it solve?

In this first part of the ReactJS Series, we'll answer all of these questions — no prior React knowledge required. By the end, you'll understand React's core idea, see how it compares to vanilla JavaScript, and write your very first React component.

What is React?

React is an open-source JavaScript library for building user interfaces. It focuses on one thing and does it well: rendering UI based on data.

React is not a full framework like Angular or a complete solution like Next.js. It's a library — a set of tools you bring into your project to handle the view layer (what users see and interact with).

Key Ideas

• Component-Based — You break your UI into small, reusable pieces called components. A button, a navbar, a card — each is its own component.
• Declarative — You describe what the UI should look like for a given state, and React figures out how to update the DOM efficiently.
• Unidirectional Data Flow — Data flows in one direction (parent → child), making your app easier to understand and debug.

Why Does React Exist?

Before React, building interactive web apps with vanilla JavaScript meant manually finding DOM elements, updating their content, and keeping everything in sync. This works for small pages, but quickly becomes painful as your app grows.

Consider a simple counter. Here's how you'd build one with plain JavaScript:

Preview

This works, but notice the pattern: you manually find the element (getElementById) and manually update it (textContent = count). Now imagine doing this for hundreds of elements across dozens of pages — tracking which elements need updating, when, and in what order. That's the problem React solves.

How React Thinks Differently

In React, you don't tell the browser how to update the DOM step by step. Instead, you describe what the UI should look like based on the current data, and React handles the rest.

Here's the same counter, but written with React:

javascript
1
2
3
4
5
6
7
8
9
10
11
12
function Counter() {
  const [count, setCount] = React.useState(0);
 
  return (
    <div>
      <h2>React Counter</h2>
      <div>{count}</div>
      <button onClick={() => setCount(count - 1)}>-</button>
      <button onClick={() => setCount(count + 1)}>+</button>
    </div>
  );
}

Notice the difference:

• No getElementById — You don't search the DOM for elements.
• No manual updates — When count changes, React re-renders the component automatically.
• UI = f(state) — The UI is a function of your data. Change the data, and the UI updates to match.

This is what declarative means. You declare the desired result, and React figures out the DOM operations.

The Virtual DOM

One of React's most important ideas is the Virtual DOM — a lightweight JavaScript copy of the actual DOM.

Here's how it works:

1. When your data changes, React creates a new Virtual DOM tree representing the updated UI.
2. React compares (or diffs) the new tree with the previous one.
3. It calculates the minimum set of changes needed.
4. It applies only those changes to the real DOM.

This process is called reconciliation, and it's why React apps feel fast — the browser only updates what actually changed, not the entire page.

Analogy

Think of it like editing a document. Instead of rewriting the entire document every time you fix a typo, you just change the specific word. That's what the Virtual DOM does for your webpage.

Components: The Building Blocks

Everything in React is a component. A component is a JavaScript function that returns a piece of UI.

javascript
1
2
3
function Greeting() {
  return <h1>Hello, World!</h1>;
}

That's a complete React component. It's just a function that returns what looks like HTML (it's actually JSX — more on that in Part 2).

Why Components?

Components let you:

• Reuse — Write a Button component once, use it everywhere.
• Compose — Combine small components into larger ones (Page → Header + Content + Footer).
• Isolate — Each component manages its own logic and appearance. A bug in one component doesn't break others.

A Real-World Example

Imagine building a social media feed. Without components, you'd have one massive HTML file. With React, you'd break it down:

javascript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
function Feed() {
  return (
    <div>
      <Header />
      <PostList />
      <Sidebar />
    </div>
  );
}
 
function PostList() {
  return (
    <div>
      <Post />
      <Post />
      <Post />
    </div>
  );
}

Each piece is independent, testable, and reusable. That's the power of component-based architecture.

React vs Vanilla JavaScript

Let's compare the two approaches side by side to make the differences concrete:

When to use vanilla JS: Small scripts, static pages, simple interactions, quick prototypes.

When to use React: Interactive UIs, single-page apps, apps with dynamic data, anything with complex state.

Your First React App (Live)

Let's put it all together. Here's a small working React app — a greeting card that updates based on user input:

Preview

What's happening here:

• React.useState("") creates a piece of state (the name) that React tracks.
• When you type, setName updates the state.
• React automatically re-renders the component with the new name — no getElementById, no textContent =, nothing.
• The UI is always in sync with the data. That's the React way.

How Do You Actually Use React?

In real projects, you don't load React from a CDN like the example above. Instead, you use a build tool or framework:

• Create React App — The classic starter (still works, but being phased out).
• Vite — A fast, modern build tool. Run npm create vite@latest my-app -- --template react and you're ready.
• Next.js — A React framework with routing, server rendering, and more (this portfolio is built with Next.js!).

All of these set up a development environment where you write React components in .jsx or .tsx files, and the tooling compiles them into optimized JavaScript for the browser.

Common Misconceptions

"React is a framework"

React is a library, not a framework. It handles the view layer only. For routing, state management, and server-side rendering, you bring in additional tools or use a framework like Next.js built on top of React.

"React replaces HTML"

React doesn't replace HTML — it generates it. JSX (which we'll cover in Part 2) looks like HTML but is actually JavaScript that produces real HTML elements.

"React is slow because of the Virtual DOM"

The Virtual DOM is an optimization, not a bottleneck. Direct DOM manipulation for every small change is what's slow. React batches and minimizes DOM updates, which is faster for complex UIs.

"You need React for every project"

You don't. A static landing page or a simple form doesn't need React. Use it when your UI has dynamic, interactive, data-driven behavior.

What's Next?

In this article, we covered:

• ✔ What React is and why it was created
• ✔ The difference between imperative (vanilla JS) and declarative (React) approaches
• ✔ How the Virtual DOM works
• ✔ What components are and why they matter
• ✔ Your first interactive React component

In Part 2: JSX & Components, we'll dive deeper into JSX syntax — the HTML-like code you write inside React components — and learn how to build, nest, and structure components properly.

Pro Tip: Before moving to Part 2, try modifying the greeting card example above. Add a second input for a last name, or change the greeting message based on the time of day. The best way to learn React is by experimenting.

Happy coding!