Exercise 3: Why Choosing by Trend/Popularity Is a Real Anti-Pattern — Possible Solution
====================================================================

THE ANTI-PATTERN ITSELF
------------------------------
Per this chapter's own warn-box, "a real, common mistake: picking a
framework or paradigm purely because it's currently trendy
('everyone uses Tailwind now'), rather than actually weighing it
against the four real factors this chapter names." Rather than
evaluating team expertise, design-system maturity, performance needs,
and accessibility requirements for the SPECIFIC project at hand, a
team following this anti-pattern simply adopts whichever paradigm
currently has the most visible popularity or industry buzz, treating
that popularity itself as sufficient justification.

WHY A GENUINELY GOOD CHOICE FOR ONE PROJECT CAN BE A GENUINELY BAD
CHOICE FOR ANOTHER
------------------------------
Per this chapter's own warn-box, "a genuinely good decision for one
project — Bootstrap for an internal admin tool with zero design
resources, for instance — can be a genuinely bad one for a different
project, regardless of which approach happens to be currently
fashionable." This chapter's own four factors (team expertise,
design-system maturity, performance needs, accessibility requirements)
are all genuinely PROJECT-SPECIFIC — they depend on the actual, real
circumstances of a specific team and a specific application, not on
anything about the framework's own general popularity. Two entirely
different projects can have completely different answers to every one
of these four factors: one project might have no design resources and
no performance-sensitivity (favoring Bootstrap), while another has a
mature, established brand and genuine performance requirements
(favoring utility-first or headless approaches). A framework's own
popularity says nothing at all about which of these two very different
situations a given real project is actually in — popularity is a fact
about the industry in general, while the four factors this chapter
names are facts about ONE SPECIFIC project.

THE PRACTICAL CONSEQUENCE
------------------------------
A team that chooses based purely on trend, skipping this chapter's own
actual evaluation, risks landing on a paradigm mismatched to their
real, specific situation — for example, adopting Tailwind purely
because "everyone uses it now," despite having no dedicated design
resources and genuinely needing the fast, complete, professionally-
designed starting point Bootstrap would have provided instead (per
this chapter's own Exercise 1 scenario). The mismatch isn't visible
from the framework's own popularity at all — it only becomes visible
by actually applying the chapter's own project-specific factors, which
is exactly what the trend-following anti-pattern skips.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states the anti-pattern precisely using the chapter's own wording,
and explains specifically why the four decision factors are inherently
project-specific in a way that popularity never is, making it entirely
possible for the same trendy choice to be right for one project and
wrong for another.