Not all frameworks make the same trade. There are two broad kinds, and telling them apart is most of knowing which to reach for.

Component frameworks vs utility-first

Component frameworks — Bootstrap is the example — hand you finished pieces. card, navbar, btn: you drop in a component and fill it with content, and the styling decisions are already made. Fast, but the look is the framework's.

Utility-first frameworks — Tailwind is the example — do the opposite. They give you hundreds of tiny, single-purpose classes — flex, pt-4, text-lg, rounded-xl — each doing essentially one CSS declaration. You compose them directly in your markup to build your own components:

<article class="flex flex-col rounded-xl border overflow-hidden">
  <img class="w-full h-52 object-cover" src="…" alt="…">
  <div class="p-4">
    <h2 class="text-base leading-snug">A Dust Angel Nebula</h2>
    <p class="text-sm text-slate-400">2016-04-28</p>
  </div>
</article>

That isn't someone else's card — it's your card from lesson 3, written as a shorthand for the CSS you already know. You still make every design decision; you just never leave the HTML or open a stylesheet. The catch is right there in that requirement: utility-first only works if you know the CSS the utilities stand for. h-52 object-cover is only readable because you wrote height: 200px; object-fit: cover by hand first. This is why utility-first comes after learning CSS, never instead of it.

Choosing — the honest guide

There's no universally right answer; there's a right answer per project. Roughly:

• Reach for a component framework when you're shipping a standard interface fast — an admin dashboard, an internal tool — a team already knows it, and the design isn't a differentiator. Speed and consistency are the whole win.
• Reach for utility-first when you want that speed and control, your team knows CSS, and you want your own design rather than the framework's default look — without writing separate stylesheets.
• Reach for hand-written CSS — what you did here — when you're learning; when the design is distinctive and brand-defining; when the performance budget is tight and every kilobyte counts; or when the site is small enough that a framework is more weight than it saves.

The point of having built it yourself

Here is what these six lessons actually bought you: the ability to make that choice well. Someone who starts with Bootstrap can't tell whether they need it — Bootstrap is all they know, so every problem looks like a Bootstrap problem. You can read what any framework generates, recognise the button and the grid and the card underneath because you've built each one, and decide, per project, whether the framework earns its weight. That judgement is the real skill. The framework is just a tool you're now qualified to pick up — or put down.