Every app screen you've ever used is three things stacked together, and once you've seen the split you can't unsee it.
There's the structure, which says what exists on the page: a heading here, a list there, a button at the bottom. That's HTML.
There's the styling, which says what it all looks like: this is blue, that's bigger, there's space around this. That's CSS.
And there's the behaviour, which says what happens when someone does something: click this and a menu opens, type here and it filters. That's JavaScript.
Structure, appearance, behaviour. Everything else in frontend work is a convenience layer sitting on top of those three.
Where frameworks come in
You'll hear about React, Vue, Svelte and a dozen others. They all exist for the same reason.
Writing a whole app in plain HTML and JavaScript works fine until things start depending on each other. Change one number and four places on screen need updating. Doing that by hand gets messy fast, and the bugs are the annoying kind where the screen and the actual data quietly disagree.
Frameworks handle that for you. You describe what the screen should look like for a given set of data, and when the data changes the screen follows. That's really all they do, underneath the terminology.
React is the most popular, which for a first project matters more than whether it's the best. More examples, more answers when you're stuck, and an AI that has seen a very large number of React apps.
Components, which are simpler than they sound
A component is a piece of screen you can reuse. A button, a card, a whole header.
Build a card component once and you can drop it in twenty places. Change how the card looks in one file and all twenty update. Without components you'd be copy-pasting the same markup around and then missing three of them when you make a change.
That's the whole idea. People write long articles about component architecture but the core of it is: name a piece of screen, reuse it, change it in one place.
The four states people forget
What separates apps that feel solid from ones that feel broken usually isn't design talent. It's this.
Any screen that shows data can be in four different situations, and most beginners build exactly one of them.
The data might still be loading, which raises the question of whether someone sees a spinner, a placeholder, or a blank white screen that looks identical to a crash. It might have arrived, in which case you show it, and this is the one everybody builds. There might be genuinely nothing to show, because the person is new and hasn't added anything yet. Or it might have failed, because the internet dropped or the server hiccuped.
The empty one is worth dwelling on. A screen that says "no results" and stops has wasted the single best teaching moment you get, because this is exactly when somebody is looking for what to do next.
Build only the loaded state and your app looks broken to every new user on their very first visit, which is the worst possible moment for it. Skip the error state and any network wobble produces a mysterious blank page nobody can act on.
When you ask Claude to build a screen, asking for all four states up front costs you one extra sentence and saves the entire round of "why does this look wrong."
Responsive, meaning it works on a phone
Most people will open your app on a phone. Designing on a laptop and checking mobile at the end is a reliable way to discover your layout falls apart at the last minute.
The practical version: make the phone layout work first, then let it spread out on bigger screens. That order is easier than squeezing a desktop design down.
Modern CSS does most of this for you if you let it. The main thing to avoid is fixed pixel widths on things that should flex. Ask for a layout that works from 320 pixels wide upward and you'll dodge most of the pain.
A quick story. On my own app, the screen I spent the most time on was the one users saw least, and the one they saw first got almost no attention until quite late.
That happens because you build in the order that's interesting to you rather than the order people experience it. You're excited about the clever feature, so that gets polished. The empty first-run screen is boring, so it doesn't.
Then someone opens it for the first time, sees the boring unfinished thing, and forms their entire opinion of the app right there. Building in the order users arrive would have caught it.
What good looks like early
You don't need a design system in week one. You need consistency, which is a different and much easier thing.
Pick a small set of spacing values and use only those. Pick three or four text sizes. Pick two or three colours plus greys. Then be boring about it and stick to them.
Most of what reads as "professionally designed" is not creativity, it's the absence of small inconsistencies. Twelve pixels here and fourteen there, four slightly different greys, three near-identical button styles. Individually invisible, collectively the reason something feels amateur.
If you want to build a screen
The four states line is the one to keep. It's the difference between a screen that demos well and one that survives contact with a real person.
Next: Where your data actually lives →
Go deeper: Chapter 11, UX Fundamentals and Chapter 17, Frontend and Web Development