The Frontend Architecture Decisions That Don't Age Well

Frontend architecture has a shorter half-life than backend architecture. Frameworks and patterns that were best practice five years ago are legacy today, and some choices that seem pragmatic in year one become the source of endless pain in year three. Having consulted on and inherited enough frontend codebases to see the patterns, here’s what consistently ages poorly.

Global State Stores for Everything

Redux, when it first arrived, was applied to everything — UI state, form state, server state, application state. The result is codebases where debugging a single UI interaction requires following state changes through five layers of reducers and middleware. Modern applications should use server state libraries (React Query, SWR) for server data and local component state for UI, reserving global state for the small amount of application state that genuinely needs to be global.

Custom Design Systems Too Early

Building a custom design system before you understand your actual design requirements is a significant investment that often needs to be replaced within two years. Start with an established component library, customize it to your needs, and build a custom system only when you have genuinely distinctive requirements that off-the-shelf solutions can’t meet.

SSR/SSG Choice Made Once, Never Revisited

The rendering architecture decisions made at project start often calcify into permanent constraints. A page that needed to be static at launch might need server rendering at scale. Choosing an architecture that can’t evolve costs you later.