Stop Thinking in Pages. Start Thinking in Components.
Demi Taylor Nimmo
Software Developer
Why Frontend Architecture Beats Pretty Designs
You’re staring at a design mockup. It looks clean. Maybe even beautiful. Your designer did their job.
Now here’s the question that separates junior developers from senior ones:
Are you seeing pages, or are you seeing systems?
Most developers look at a mockup and see what to build. Good developers look at a mockup and see how it should be built.
They’re not thinking about the final UI. They’re thinking about the component architecture that makes it possible.
This is component-level thinking. And it matters more than the design itself.
The Real Problem With “Just Build What’s Designed”
Here’s what happens when you think in pages instead of components.
First sprint: You build a user profile page. It has a card with user info, some stats, and an edit button. Looks good. Ships on time.
Second sprint: You build a team members page. It also needs cards with user info, stats, and actions. The designer made them slightly different. So you copy-paste, tweak, and ship.
Third sprint: Settings. Admin dashboard. Notifications. Each needs similar layouts. Each gets its own slightly different implementation.
Six months later: You have dozens of ways to display the same information. None behave exactly the same. Updating one doesn’t update the others. The codebase is fragile.
You didn’t fail because you’re bad at CSS. You failed because you were thinking in pages instead of components.
I learned this the hard way.
The Turning Point: Implementing a Shared Component System
I was working on a complex platform with multiple teams shipping features in parallel.
Velocity mattered. Features shipped fast. The frontend grew quickly.
Too quickly.
Different teams implemented the same UI patterns in different ways. Buttons behaved inconsistently. Forms handled validation differently. Loading and error states weren’t standardised.
The breaking point came when a design system update required touching dozens of files across multiple micro-frontends. What should have been a small change took days.
That’s when the question shifted from:
“How do we build this feature?” to “How should this UI exist across the system?”
I focused on implementing reusable UI components using StencilJS and Storybook — components with clear contracts, shared styling tokens, and documented behaviour. Over time, the team took governance of the library and formalised it as shared infrastructure.
The impact wasn’t that developers suddenly coded faster. It was that they stopped rewriting the same UI over and over.
Build times dropped. UI inconsistencies reduced. New features reused existing components by default.
To users, nothing looked different. To developers, everything became easier.
Component-Level Thinking: The Real Skill
Component-level thinking means looking at a design and asking:
- What are the repeating patterns — visually and behaviourally?
- What will change? Props? State? Context?
- What stays the same? Layout? Validation? Interaction rules?
- Where are the boundaries?
- Will this exist once — or everywhere?
When you look at a user profile mockup with this mindset, you don’t see a page. You see:
<UserCard>— reusable, data-driven<StatDisplay>— formatting, icons, labels<ActionButton>— permissions, loading states<Avatar>— images, fallbacks, sizing<BadgeList>— consistent tag rendering
Same design. Completely different architecture.
Why This Matters More Than Design
A beautiful design implemented poorly becomes a maintenance nightmare.
A decent design implemented with strong component architecture becomes:
- Maintainable — change once, update everywhere
- Consistent — predictable UI patterns
- Scalable — new features reuse existing components
- Fast — composition over reconstruction
- Testable — clear, isolated contracts
Design is temporary. Architecture is forever.
When a designer asks for a “small tweak” six months later, component-level thinking means one change. Page-level thinking means hunting through files and hoping nothing breaks.
Real-World Example: Micro-Frontend Architecture
When the platform moved to micro-frontends, the hardest problem wasn’t splitting pages.
It was defining shared component boundaries.
Each team owned its domain logic. They all shared:
- Core UI components
- Layout primitives
- Common data display patterns
That shared foundation prevented drift and duplication. It allowed teams to move independently without fragmenting the frontend.
From Legacy Systems to Component-First Thinking
Earlier in my career, I worked on large legacy frontend systems built around page-level architecture.
Changes were risky. Testing was brittle. Onboarding took too long.
Breaking pages into isolated components didn’t just improve code quality — it reduced the surface area for bugs to exist.
Each component had one job. Each was testable in isolation. The system became easier to reason about.
How to Start Thinking in Components
Before you write code:
- Print the mockups
- Draw boxes around repeating patterns
- Define data contracts
- Account for all states, not just the happy path
While you’re building:
- If you copy-paste, extract
- If a prop exists “just for this case,” stop
- If a component grows too large, split it
After you ship:
- Did design changes touch one place or many?
- Could another developer use it without explanation?
- Is deleting a feature straightforward?
The Component Mindset
Senior developers don’t just build components. They recognise systems.
They see patterns in products, not pages. They optimise for scale, not screenshots.
Page-level thinking ships features. Component-level thinking builds products.
Start Small
You don’t need to architect everything upfront.
You just need to stop thinking in pages.
Spend a few minutes defining component boundaries before writing code.
You’ll write less. Your code will scale better. And future-you will be grateful.
Design is what users see. Components are what developers build.
Master the second — and the first takes care of itself.
Enjoyed this post?
