Lesson 1.1 · 11 min read
You've been looking at HTML, CSS, and JavaScript for years without knowing it. Every website you've ever admired, every interface you've designed a version of, every button you've clicked, was these three things working together. They are the entire material of the web's surface. Everything a user sees and touches in a browser is built from exactly these three, and nothing else.
Here's the good news for you specifically. This is the layer closest to what you already do. You've spent your career thinking about structure, visual style, and interaction, which turns out to be the exact three jobs these three technologies handle. You're not learning a foreign world here. You're learning the names and mechanics of things you already have deep instincts about. The goal of this post isn't to make you write these from memory. It's to make you understand what each one is truly responsible for, because that understanding is what lets you read the code AI generates, know which of the three to reach for when something's wrong, and direct changes with precision instead of guessing.
Let's meet them one at a time, and then watch them work together.
There's a classic way to explain these three, and it's classic because it's genuinely accurate, so we'll use it, but properly.
Think of building a house. First you build the structure: the walls, the floors, the rooms, the doorways. This is the raw skeleton that determines what exists and where. It's not pretty yet. A house at this stage is bare concrete and framing, but every room is there and in its place. Then you decorate: paint the walls, choose the flooring, hang the lights, arrange the furniture. Nothing about what exists changed; you're deciding how it all looks. Finally, you make it functional in a living way: the light switches actually turn on lights, the doors lock, the thermostat responds when you touch it. Now it's not just a structure that looks nice. It does things when you interact with it.
Those three stages are exactly HTML, CSS, and JavaScript. HTML is the structure. CSS is the decoration. JavaScript is the behavior. And the reason this separation is worth taking seriously, rather than just memorizing, is that it's one of the most important design principles in all of software: keep the thing, the look of the thing, and the behavior of the thing as three separate concerns, so you can change any one of them without disturbing the others. Repaint a room without knocking down walls. Rewire a switch without repainting. That separation is a feature, and once you see why, a lot of how frontend code is organized suddenly makes sense.
HTML stands for HyperText Markup Language, and its single job is to define structure and content. What is on this page, and what is each piece? A heading. A paragraph. An image. A button. A list. A form field. HTML is how you declare that these things exist and give each one a meaning.
The critical thing to understand about HTML is that it is not about appearance. When you write HTML that says "this is a heading," you are not saying anything about how big it is, what color it is, or what font it uses. You are only saying what it is: this piece of content is a heading, the most important title on the page. It's like labeling the rooms on an architectural blueprint. This is the kitchen, this is a bedroom, this is a hallway. The blueprint declares what each space is and how the spaces are nested inside each other. It says nothing about paint or furniture. That's deliberate, and it's the whole point.
Here's the question that section raises and doesn't answer. If HTML says what each thing is, and says nothing about how it looks, then who cares what it is? Why does it matter whether you declare something a heading or just style some text to be large and bold?
It matters because things other than eyes read your page.
A screen reader, used by someone who cannot see the screen, navigates a page by its structure. It offers a list of headings so a person can jump to the section they want, exactly as a sighted person scans a page. If your headings are headings, that works. If they are text styled to look large, there are no headings, and the page is an undifferentiated wall with no way through it. A button that is genuinely a button can be reached by keyboard, activated with a spacebar, and announced as a button. A styled div that responds to clicks can do none of those things, and a person navigating without a mouse simply cannot use it.
Search engines read structure too. So do browser reading modes, translation tools, and anything else that needs to understand a document rather than render it.
This is what semantic HTML means: choosing elements for what the content is rather than for how they happen to look. A navigation region, a heading, a list, a button, a form label bound to its input. The visual result can be identical either way. The difference is whether the page carries meaning or only appearance.
For a designer this should land with some force, because it's a design decision made in code, and it is routinely made badly by people who were thinking about layout. Accessibility is not a compliance checklist bolted on afterwards. It's the natural consequence of using HTML for the job it was built to do, which was never appearance. It was structure and meaning, and meaning is what makes a page usable by someone who isn't looking at it.
When an AI generates markup and every element is a div, the page will look right and mean nothing. You are the person on the team most likely to notice, and most likely to care.
HTML also establishes hierarchy, which matters more than it first appears. Content sits inside other content. A page contains a header, which contains a navigation bar, which contains a list of links. This nesting, this tree of things inside things, is the actual structure of every page you've ever seen, and it's something you already understand deeply, because it's the same nesting you use when you group and layer elements in a design tool. A frame contains a card, which contains an image and a text block. HTML is that exact idea, written down. When you group layers in Figma, you're building an HTML tree in spirit, without knowing it.
CSS stands for Cascading Style Sheets, and this is the layer you, as a designer, will feel most at home in, because CSS is pure visual design expressed as code. Everything about how a page looks is CSS. Colors, fonts, sizes, spacing, alignment, shadows, rounded corners, the whole visual language you already think in fluently. CSS is where "this is a heading" becomes "this heading is 32 pixels, deep charcoal, in this typeface, with this much space beneath it."
The relationship between HTML and CSS is worth sitting with, because it's a clean example of that separation-of-concerns principle in action. HTML says what exists. CSS reaches in and says how each of those things should look. They're kept apart on purpose, and the payoff is enormous. Because the styling lives separately from the structure, you can completely transform how a site looks, a total visual redesign, without touching the structure at all. Same rooms, entirely new paint and furniture. This is exactly how a company can roll out a fresh visual identity across an entire product without rebuilding what the product actually contains. The content and structure stayed still. Only the CSS changed.
The word "cascading" hints at something you'll appreciate as a designer: CSS has a system of rules that flow and inherit, so you can set a font for the whole page once and let every piece of text inherit it, then override just the specific spots that need to be different. It's the same logic as a design system with global styles and local overrides. If you've ever set up text styles or color tokens that cascade through a design, you already understand the core instinct of CSS. It's your world, in a new syntax.
JavaScript is the third layer, and it's the one that's genuinely different from the other two, because it's the only one that's truly a programming language. HTML and CSS describe things. JavaScript makes things happen. It is the layer of behavior, logic, and interactivity, everything that responds, changes, and reacts while the user is there.
Here's the clean way to feel the difference. HTML and CSS build a button that exists and looks perfect. But that button does absolutely nothing when clicked. It's a photograph of a button. JavaScript is what makes the click do something: open a menu, submit a form, load more content, play an animation, update a number, show an error. Any time a page reacts to you, changes without a full reload, checks what you typed, or responds to your action in the moment, that's JavaScript at work. Going back to the house, JavaScript is the electrical and plumbing systems. The switch that turns on the light, the tap that runs water, the thermostat that responds to your touch. It's what makes a structure into something that actually functions when you live in it.
Because JavaScript is a real programming language, it's also where genuine complexity and genuine power live. It can hold logic, make decisions, do calculations, talk to servers, remember things, and respond to sequences of events. This is why it's the layer that takes the most understanding, and it's the layer we'll spend the most time on across this module. But the mental model to lock in right now is simply this: if it does something rather than just is or looks like something, it's JavaScript.
The magic isn't in any one of these. It's in how they layer, and seeing one real example click together is worth more than any definition.
Picture a "like" button on a post. HTML declares it into existence: there is a button here, and next to it, a number showing the count. That's structure. Content that exists. CSS makes it look right: the button is a heart shape, soft grey when inactive, the count sits beside it in a particular size and color with the right spacing. That's style. Now it exists and looks perfect, but it's completely inert. Tapping it does nothing. Then JavaScript brings it alive: when you tap, it detects the tap, changes the heart from grey to red, adds one to the count, and quietly sends a request to the server to record that you liked this, exactly the kind of request from our very first post. That's behavior.
Three layers, three jobs, one button. And now notice how cleanly the separation serves you. A designer wants the heart to be a different shade of red? That's CSS alone; nothing else is touched. Someone wants the like to also trigger a little celebration animation? That's JavaScript, added on top, with structure and style untouched. The design changes and the behavior changes live in different places, so they don't collide. This is why the separation isn't bureaucratic tidiness. It's what makes a product changeable without everything breaking every time you adjust one thing.
Let me connect this directly to your actual work with AI, because this is where the understanding pays for itself.
When you prompt an AI to build a piece of interface, it generates all three of these layers for you, woven together. Without the mental model you now have, that output is an undifferentiated wall of code, and when something's wrong, you're stuck pasting the whole thing back and hoping. With the model, that same output becomes readable in a completely different way. The spacing looks off? You know that's CSS, and you can say so precisely: adjust the styling, the spacing specifically. The button looks perfect but doesn't respond when clicked? You know instantly that the structure and style are fine and the behavior is missing or broken, so it's a JavaScript problem, and you can direct the AI straight at it. You've turned "something is wrong somewhere" into "this specific layer needs this specific fix." That precision is the difference between flailing and engineering.
It also makes you far better at describing what you want in the first place. Instead of a vague "make it look nicer and work better," you can separate your intent the way the technology itself is separated: here's what should exist, here's how it should look, here's how it should behave. You're speaking in the same joints that the code is built along, which means the AI, or an engineer, or future you, can act on it cleanly. This is a real, repeatable advantage, and it comes entirely from understanding that the surface of every web product is three separate layers, each with one honest job.
Do this before the next post
Go back to the browser inspector one more time, but with a new focus. Open any website, right-click on some text or a button, and choose "Inspect." This time the panel opens on the Elements tab instead of Network.
What you're looking at is the live HTML of the page, the structure, the tree of things inside things. Hover over different lines and watch the browser highlight the matching piece on the actual page. You're seeing the skeleton directly. Now look to the side, where there's a panel of styles. That's the live CSS, every color and size and spacing rule, applied to whatever element you've selected. Try changing one: find a color value, double-click it, type a different color, and watch the page change in front of you. You've just edited CSS on a live site, and touched nothing structural to do it.
You won't find JavaScript as easily here, because behavior isn't visible the way structure and style are; it only reveals itself when things happen. But you've now seen two of the three layers directly, laid out separately exactly as we described, on a real page you didn't build. That's the moment the abstract becomes concrete. Spend five minutes poking at it. It's the fastest way to make this post permanent.