Ten connected frontend decisions
Rendering, component ownership, state, validation, data, accessibility, assets, motion, testing, and deployment affect one another. A strong product makes those choices work together.
A frontend is not React plus a few packages. It is a set of choices that either reinforce one another or quietly fight for years.
Most expensive rebuilds do not begin with one terrible tool. They begin with ten reasonable decisions made in isolation. This guide gives each decision a place, then points to the deeper guides when you need the detail.
1. Start with rendering
Ask what arrives first and what must stay interactive. A content heavy page often benefits from a static first approach. An application screen with long lived client state has different needs. Read Astro 5 and server islands, React 19, and SvelteKit as architecture decisions, not framework tribalism.
2. Own component boundaries
Choose whether components are imported as a package, copied as maintained source, or built from primitives. The useful question is who changes the button when the product changes. Go deeper with shadcn/ui and open code, Radix UI, and Storybook for shared states.
3. Make state boring
Keep state close to where it is used until there is a real shared need. Global state is not a badge of seriousness. When the boundary is real, read Zustand state management and pair it with a component API that makes loading, empty, and error states explicit.
4. Treat forms as a two boundary system
Browser validation helps people. Server parsing protects the action. The same schema can reduce duplication without making the browser authoritative. See React Hook Form and Zod, the wider form pattern, and form experience decisions.
5. Design data failure before data success
Every request can be slow, unavailable, malformed, or stale. Define the visible response before connecting the happy path. Fetch patterns and API design patterns cover the contracts underneath the interface.
6. Accessibility is component behaviour
Accessible work is not a final checklist. It is names, focus, keyboard paths, status messages, and honest native controls. Start with the ARIA attributes that matter, then test the actual component states that people use.
7. Give assets a budget
Images, fonts, video, and interactive scenes compete for attention and bandwidth. Choose responsive sources, reserve layout space, and load below fold work late. Read responsive images and lazy loading before adding another visual dependency.
8. Motion should explain, not decorate
Use motion to show a state change, a relationship, or a result. Keep a still reading path and respect reduced motion. Compare scroll triggered animation, CSS scroll animation, and GSAP patterns.
9. Test the boundary between decisions
Unit tests catch local logic. Product failures often happen between systems: an API error inside a dialog, a form under slow network, or focus after a transition. Write a few journey tests that cross those boundaries.
10. Let product need choose complexity
The best stack is the smallest one that can make the next useful change safely. When a new library enters the project, name the customer problem, owner, fallback, and removal path.
Velocity Components is built around that standard: visible states, editable source, and less mystery between design and engineering.