Start learning
Part 3/Web Components

From the orbital height

Before you write a single line of custom-element code, it helps to know what problem web components actually solve. This chapter opens the topic from a distance, then the following chapters zoom into the mechanics.

Web components are a family of browser standards. Some pieces are stable and already baked into the HTML and DOM specs. Others are still moving. Every example here runs in a modern browser, and Chrome tends to track the newest behavior most closely, in part because much of the specification work happens there.

The idea isn’t new

Splitting a program into components is an old habit. React, Vue, Angular, Svelte, and countless older systems all lean on it. Web components take that habit and push it down into the browser itself, so you no longer have to fake it with naming conventions and tooling.

To get why this matters, look at one of the most complex machines humans have ever built.

assembled: one complex whole
One machine, many modules: pressurized cylinders strung along a central truss, with solar arrays at each end

That’s the International Space Station. Here’s roughly how it fits together on the inside.

Lab moduleteam AHabitatteam BDocking nodeteam CAirlockteam DPower trussteam E
Pulled apart: each module is a self-contained unit, and different teams built different modules

A few things stand out about how the station is built:

  • It’s assembled from many distinct modules.
  • Each module is itself packed with smaller parts.
  • Any single module is far more intricate than almost any website.
  • Different national teams, working in different languages, built different modules.

And the whole assembly flies, and keeps people alive in orbit.

So how do you build something that complicated without it collapsing under its own weight? And which of those ideas can you steal to make your own code more reliable and easier to scale?

Component architecture

The classic rule for building complex software sounds like a joke: don’t build complex software.

The real meaning is sharper. When a thing gets complicated, break it into simpler pieces and wire those pieces together in the most obvious way you can.

A user interface splits the same way. You carve it into visual components. Each one owns a spot on the page, performs a well-defined job, and stays independent of its neighbors.

Take a social feed like Twitter. It falls apart into obvious blocks.

1Top navigation2User info3Followsuggestions4Compose form5Message6Message7Message
A social feed page carved into labeled components — nav, profile, suggestions, a compose form, and the messages themselves
  1. Top navigation.
  2. User info.
  3. Follow suggestions.
  4. The compose/submit form.
  5. (plus 6 and 7) individual messages.

Components nest. A message might live inside a “message list” component. The clickable avatar inside that message could be its own component too, and so on down.

Page
Navigation
MessageList
Message
Message
Message
SubmitForm
Components form a tree — each parent owns its children, and children stay independent of their siblings

How do you decide where one component ends and the next begins? There’s no formula. It comes from intuition, experience, and plain common sense. A good candidate is usually a self-contained visual unit you can describe in a sentence: what it does, and how it talks to the rest of the page. On the feed above, each block clearly plays its own role, so making each one a component reads naturally.

A well-formed component tends to carry four things:

  • Its own JavaScript class that drives the behavior.
  • A DOM structure managed only by that class. Outside code doesn’t reach in and poke at it. This is the encapsulation principle.
  • CSS styles that apply to the component and don’t leak elsewhere.
  • A public API — events it fires, methods it exposes — that other components use to interact with it.
<user-card>
private inside
internal DOM
scoped CSS
class state
← methods()
events →
outside code sees only the API, never the guts
A component draws a boundary: internals stay private, only the API crosses the line

None of this is exotic. Plenty of frameworks and methodologies already give you components, each with its own conventions. Most of them lean on special CSS class naming and discipline to fake two things the browser historically didn’t provide: CSS scoping and DOM encapsulation.

Web components change that by baking these capabilities into the browser. You stop emulating encapsulation and start getting it for real.

The standards involved

“Web components” is an umbrella over several separate specifications. Each one covers a different slice of the problem.

Custom Elements
Define your own HTML tags with attached behavior.
Shadow DOM
Give a component a private internal DOM, hidden from the page.
CSS Scoping
Styles that apply only inside the component’s shadow tree.
Event retargeting
Adjusts event targets (and other small touches) so components behave predictably.
The four building blocks and what each one contributes
  • Custom elements — for defining your own HTML elements.
  • Shadow DOM — for building an internal DOM inside a component, hidden from the rest of the page.
  • CSS Scoping — for styles that stay confined to a component’s Shadow DOM.
  • Event retargeting and other small refinements that make custom components fit smoothly into everyday development.

The next chapter digs into Custom Elements. It’s the foundational piece, it’s well supported, and it’s genuinely useful even on its own.