Setting up a React project with Vite
The mental model: how React renders (2)
You've spent weeks learning JavaScript. You can manipulate the DOM, respond to events, fetch data, and build interactive pages. So why do we need React at all?
The short answer: because keeping a UI in sync with your data gets painful fast. The longer answer is what this lesson is about.
https://www.youtube.com/watch?v=Tn6-PIqc4UM
Building interactive UIs with plain JavaScript means you're constantly answering three questions: which DOM nodes need to change, what do they need to change to, and when should the change happen. You select elements with querySelector, update their content with innerHTML or textContent, and wire up event listeners to make it all happen.
Here's a counter built the vanilla way:
<button id="btn">Click me</button>
<p id="count">0</p>
const button = document.querySelector('#btn');
const display = document.querySelector('#count');
let count = 0;
button.addEventListener('click', () => {
count = count + 1;
display.textContent = count; // We have to remember to update the DOM
});
This works. It's also fragile. The count lives in two places: the count variable and the text inside the <p> element. If you forget to update display.textContent, they drift apart. Now imagine this counter is one of hundreds of pieces on a page, each with its own data, each needing to update at different times. That's how Facebook's UI looked in 2011, and that's why they built React.
This style is called imperative programming: you give the browser step-by-step instructions for how to change the page.
React flips the problem around. Instead of telling the browser how to update the DOM, you describe what the UI should look like for a given piece of data. React figures out the rest.
function Counter() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(count + 1)}>{count}</button>;
}
Look at what's missing. No querySelector. No addEventListener. No innerHTML. We never touch the DOM. We describe the button in terms of count, and whenever count changes, React updates the screen for us.
This is called declarative programming: you describe the result, not the steps.
<aside> 💡
Info
Don't worry about useState yet, we'll cover it properly in week 8. For now just notice how much less code there is, and how we never reach into the DOM.
</aside>
React rests on three ideas that work together.
A component is a reusable piece of UI. A button, a card, a form, a navigation bar — anything you'd draw a box around on a design. You build components once and use them wherever you need them, each time with different data.
You'll write your first component in the next lesson.
You describe the UI as a function of data. "Given this list of projects, render this grid of cards." React handles the actual DOM updates when the data changes.
Data flows downward, from parent components to children, through something called props. A parent can pass data to its child, but the child cannot reach up and modify the parent's data directly. This constraint sounds limiting at first, but it makes apps dramatically easier to reason about: when something on the screen is wrong, you know the data came from somewhere above it.
<aside> ⌨️
Hands On
Open a website you use regularly: GitHub, Airbnb, YouTube. Look at the page and mentally draw boxes around the repeated pieces. A video thumbnail. A list item. A comment. These are the shapes of components. For one of those repeated pieces, ask yourself: what's the same in every copy, and what's different? The "same" part is the component's structure. The "different" part is the data passed in as props.
</aside>
React only handles the UI layer. Routing, data fetching, forms, animations, state management beyond the basics — all of that is left to you. You pick the tools you want.
This is different from Vue or Angular, which ship with opinionated solutions for most of those concerns out of the box. Neither approach is better, they're tradeoffs. React's flexibility means a real-world React app is React plus five to ten supporting libraries you chose yourself. You'll get a feel for the ecosystem over the coming weeks — we've already decided on Vite as the build tool, and you'll meet React Router, React Query, and others as we go.
<aside> 😄
Inspirational
"I'm not a great programmer; I'm just a good programmer with great habits." — Kent Beck
React is a habit-forming library. The patterns feel strange for a week or two, then they feel obvious, then you start seeing them everywhere.
</aside>
There are other libraries doing similar things — Vue, Svelte, Solid, Qwik. Why are we teaching React?
Before we write any code, get used to looking at UIs through the component lens. A page isn't one big HTML document anymore — it's a tree of small, focused pieces that compose together.
A project card on your portfolio page might contain an image component, a title component, a tag list component, and a button component. That project card itself lives inside a project grid component, which lives inside a page component, which lives inside your app. Each piece does one thing. Each piece can be reused. Each piece receives the data it needs as props.
This shift in how you see interfaces is the single biggest mental change in moving from vanilla JavaScript to React. The syntax you'll learn this week is easy. The thinking takes a bit longer.
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.