React is, today, the most widely used library for building web user interfaces, and understanding what problem it solves matters far more than memorizing its API. Before writing a single line of code, it's worth being clear on why thousands of teams abandoned manual DOM manipulation and adopted a declarative, component-based model. In this lesson you'll see that contrast through a real example, get acquainted with React's basic vocabulary, and meet CicloUrbano, the bike rental app you'll build throughout the course.

1. The problem: manipulating the DOM by hand
2. The same screen with React: the declarative approach
3. What React actually is (and isn't)
4. The interface as a function of state
5. A brief history and where things stand today
6. The vocabulary you'll see from now on
7. When React fits and when it doesn't
8. Introducing the project: CicloUrbano

Picture a very simple CicloUrbano screen: a list of bikes with their model, status and price per hour, plus a filter to show only the available ones. With plain JavaScript and direct DOM manipulation, the code looks something like this.

This code works. The problem isn't its length — it's what happens to it as the application grows:

• Manual synchronization. The data lives in bikes and availableOnly, but the screen lives in the DOM. Nothing guarantees they agree with each other — it's on you to call renderCatalogue() at exactly the right moment. The day a teammate adds a new action and forgets that call, the screen will show stale information.
• Instructions, not descriptions. The code doesn't say what the screen should look like; it says what steps to take to get there (createElement, append, textContent...). Reading it forces you to mentally simulate its execution.
• Wiping and repainting everything is crude. container.innerHTML = '' destroys and recreates everything: keyboard focus, scroll position, and the state of any form field inside are all lost.
• Multiplicative complexity. With one filter, it's manageable. Add a search box, a sort order, a counter, a station badge and a booking button, and the number of combinations you have to keep consistent grows far faster than the number of features.

Now here's the same functionality written with React. You don't need to understand every detail yet — just pay attention to the shape of the code.

Compare both versions side by side:

The key difference boils down to a single sentence: the imperative version describes transitions; the declarative version describes destinations. You declare, "given this data, the screen looks like this," and React works out what needs to change in the DOM to get there. Exactly how it works that out is the subject of the lesson How React Renders: Virtual DOM and Reconciliation.

React is a JavaScript library for building user interfaces using components. It's worth unpacking that definition:

• A library, not a framework. React focuses on one thing: producing and keeping the UI up to date. It doesn't ship a router, an HTTP client, a forms system, a global state manager, or a folder convention. You choose those pieces from the ecosystem yourself (you'll see React Router in Module 6 and Redux in Module 7). That means more freedom, and also more decisions.
• Declarative. You describe the outcome, not the procedure, as you just saw.
• Component-based. The unit of construction is the component: a function that returns a piece of UI. Components nest inside one another to form a tree, much like HTML tags, but with the advantage that they're your own pieces — named, reusable, and testable in isolation.
• Agnostic about the target. React describes the interface; something else — a renderer — paints it. react-dom paints it in the browser, React Native paints it with native iOS and Android components (you'll see this in 10-05), and there are renderers for terminals and PDFs too. That's why the react package and the react-dom package are separate.

What React is not: it isn't a new language (it's JavaScript), it isn't a substitute for HTML and CSS (you still need both), and it isn't a magic performance solution (a poorly written React app can run slower than a well-built static page).

The idea underpinning all of React fits into one conceptual expression:

In other words: the screen is the result of applying your components to the current data. If the state is "the filter is off and there are three bikes," there is one screen, and only one. If the state changes to "filter on," React conceptually recalculates the screen from scratch and updates the real DOM with the differences.

The practical consequences of this model are huge:

• There's only one source of truth. If you want to know why the screen looks the way it does, you look at the state. There's no third place where someone quietly modified a textContent on their own.
• Debugging gets easier. Reproducing a bug becomes reproducing a state.
• The flow is predictable. Interaction → state change → new render. Always in that order, always in that direction.

Facts worth keeping in mind:

• It's maintained by Meta along with a large group of outside contributors, and it's released under the MIT license.
• It's the most in-demand front-end technology in the web job market, which translates into abundant documentation, courses, component libraries, and answers to concrete problems.
• The official documentation (react.dev) was rewritten from scratch around hooks: if you find a tutorial full of class ... extends React.Component, it's almost certainly outdated. In this course, class components appear only as legacy code you need to know how to read (lesson 02-02).

These four terms run through the whole course. Here we just name them; each one gets its own lesson.

React shines when the interface is state-rich: lots of data changing, lots of views that depend on it, and lots of interaction. A CicloUrbano operator panel that shows in real time which bikes are rented out is a textbook case. A three-page static brochure is not.

Signs you don't need React:

• The page is essentially content with little or no interaction.
• SEO and first-load time are critical, and you're not going to set up server-side rendering.
• The team is very small and the functionality fits into a handful of event handlers.
• A server-side solution (templates) already solves the problem with fewer moving parts.

Signs you do:

• There's shared state across several areas of the screen that needs to stay in sync.
• The interface is made up of pieces that repeat with different data (cards, rows, filters, modals).
• You expect the app to grow, with several people working on the same code.
• You need frequent updates without reloading the page.

Throughout the course you'll build CicloUrbano, a fictional app for renting urban bikes by the station. Each lesson adds a piece, so that by the time you reach Module 11 you'll have a complete application rather than a collection of disconnected examples.

All the data is fictional: the names, emails and stations are invented for the course. Never use real people's data when you practice.

In product terms, CicloUrbano will let you:

1. Browse the bike catalogue with each bike's model, type, status and price per hour.
2. Filter by type, status and station, and search by model.
3. View a station's details, including its bikes and free docks.
4. Create a booking through a validated form.
5. View the user's list of bookings and cancel them.
6. Provide an operator panel with role-restricted access.

• Thinking React replaces HTML, CSS or JavaScript. It doesn't. The better you know the DOM, the CSS cascade and promises, the better your React code will be. If any part of ES6+ feels shaky, brush up on it now: destructuring, spread, map/filter and arrow functions show up in literally every lesson.
• Trying to touch the DOM "by hand" inside a component. A document.getElementById(...).innerHTML = ... inside React clashes directly with what React believes is rendered. There are legitimate ways to access the DOM when you truly need to (useRef, lesson 05-03), but they're the exception.
• Choosing React just because it's trendy. Justify the decision: is the state rich? Does the interface change a lot? Is the team going to grow? If the answer to all three is no, you might not need it.
• Learning by copying instead of writing. Type out the examples in this course in your own project. The muscle memory for JSX syntax comes from writing it, not reading it.
• Confusing "declarative" with "automatic". React automates DOM updates, not the design of your state. Modeling your data well is still your job, and it's the decision that will have the biggest impact on code quality.

In the imperative snippet from section 1, identify the four distinct responsibilities the programmer takes on that, in the React version, disappear or get taken over by the library. Write them in your own words.

For each of these four projects, decide whether you'd use React or not, and justify your answer in two or three lines:

1. CicloUrbano's legal notice page: static text, no interaction.
2. An operator panel that shows the status of 200 bikes and refreshes every 10 seconds.
3. A four-field contact form on a corporate website built with server-side templates.
4. CicloUrbano's customer-facing app: catalogue, filters, bookings and personal area.

Write the JavaScript object for a new CicloUrbano bike that meets all these conditions, matching exactly the shape of the domain defined in section 8: it's the "Cargo Max" model, it's available, it's located at the "Central Station" station, and it costs €5.50 an hour. Then write the expression that, starting from the bikes array, returns only the available bikes at station est-01.

Solution 1.

1. Building the DOM node by node: creating each element, assigning classes and text, and attaching them to the container. In React, you describe the result with JSX and the library creates the nodes.
2. Clearing the previous output before repainting (innerHTML = ''). React calculates the differences and only changes what's changed, without destroying the rest.
3. Deciding when to repaint: remembering to call renderCatalogue() after every change. In React, changing the state triggers the new render automatically.
4. Keeping secondary elements in sync (the counter and the button's text). In React, both are expressions derived from the state, so they can never fall out of sync.

Solution 2.

1. No. Static content with no state: HTML and CSS are enough. Adding React increases load and maintenance cost without adding anything.
2. Yes. Plenty of state, constantly changing and shared across several areas of the screen: exactly the scenario React was designed for.
3. Probably not. A standalone form inside a server-rendered website can be handled with standard JavaScript. Bringing in React would mean setting up an entire build process for very little gain. If, down the line, there were many forms with complex validation, the decision could change.
4. Yes. Many views sharing data, navigation between pages, constant interaction and a team that will grow: React brings structure, reusability and an ecosystem.

Solution 3.

Notice that type is inferred from the model ("Cargo Max" is of type 'carga'), and that the station is referenced by its id, never by its name: identifiers are stable, while names could change.

React solves one very specific problem: keeping the interface in sync with the data without you having to orchestrate every DOM update yourself. It does this with a declarative model ("this is what the screen looks like given this data") that's component-based (named pieces that combine and get reused), summed up in the idea that the interface is a function of state. It's a library, not a framework: it gives you the UI layer and lets you choose the rest. It fits when there's rich state and constant interaction, and it's overkill when the page is essentially static content.

You've also now met CicloUrbano, its domain, and the sample data that will reappear in every lesson of the course.

In the next lesson, Setting Up the Development Environment, you'll move from theory to practice: you'll install Node.js, create the CicloUrbano project with Vite, understand what each generated folder is for, and get the development server running with hot reload.