Making interfaces easier to maintain
The small frontend decisions that keep a growing website consistent without turning every component into an abstraction.
A frontend can look excellent today and still become painful to maintain six months later. The problem usually starts with small decisions: duplicated content, inconsistent spacing, components that do too much, and styles that only make sense on one page.
Maintainability starts with repetition
When the same concept appears in several places, it should usually have a clear home. Content, behavior, and visual rules should not all be duplicated independently.
- Repeated content belongs in structured data.
- Repeated behavior belongs in reusable components.
- Repeated visual rules belong in shared styles or design tokens.
- Repeated page structures deserve layout components.
Do not abstract everything
Reusable components are useful, but abstraction has a cost. A component that tries to handle five unrelated use cases can become harder to understand than the duplicated code it replaced.
Good abstraction removes repetition without hiding the reason something exists.
A practical component checklist
- Give the component one clear responsibility.
- Keep its public props understandable.
- Avoid page-specific logic when possible.
- Use semantic HTML before reaching for custom behavior.
- Keep accessibility requirements part of the component design.
Semantic HTML is still underrated
Using a button as a button and a link as a link gives you keyboard behavior, accessibility semantics, and browser behavior without rebuilding those things manually.
Content should not be trapped inside JSX
Large amounts of repeated text inside component markup make content updates unnecessarily difficult. Structured data also makes filtering, searching, localization, and future CMS integration easier.
What I try to optimize for
- Readable component files
- Predictable naming
- Small interactive boundaries
- Accessible HTML
- Centralized repeated content
- Minimal unnecessary dependencies
FAQ
When should I create a reusable component?
Create one when the same behavior or structure appears repeatedly, or when isolating a piece of functionality makes the page significantly easier to understand.
Is duplicated code always bad?
No. Small duplication can be preferable to creating an abstraction too early. The important question is whether the duplicated code represents a stable concept that should evolve together.
How important is accessibility for a portfolio website?
It matters even for small websites. Semantic markup, keyboard navigation, readable contrast, useful labels, and sensible focus behavior improve the experience for many users.