Frontend Systems Over Frameworks

Every few years, something new arrives that feels like it's going to change everything. When I started in 2006, it was jQuery. Then it was Angular. Then React. Then the React ecosystem splintered into routing solutions and state management libraries and build tools. Now it's Server Components and meta-frameworks and the edge. Each wave has genuinely changed how we build things. But I've noticed something: the developers who navigate these transitions most smoothly aren't always the ones who knew the new framework earliest. They're the ones who understood the underlying system deeply enough that the new thing made sense to them quickly.

I spent years working in codebases I didn't start. Marketing platforms, tourism systems, campaign tools built by people who'd moved on. The framework was always different. The problems were usually the same: state that had spread further than it should have, components that knew too much about each other, integration points that nobody wanted to touch because they might break something. The framework choice explained almost nothing about why these problems existed. The thinking behind the system explained everything.

What I mean by systems thinking in frontend is something like this: being clear about what owns what. What manages state, and where does that state live? What's a side effect, and what causes it? Where are the boundaries between things that are likely to change independently? These questions matter in React, but they also mattered in Angular, and they mattered in jQuery, and they'll matter in whatever comes next.

This doesn't mean frameworks don't matter. They shape what's easy and what's hard. Next.js makes server rendering easy; that influences how you think about data fetching. React's component model makes certain kinds of composition natural; that shapes your architecture. But the framework is a set of constraints and affordances, not a solution to the underlying design problem. You still have to think.

The practical upshot, for me, is that I try to be technology-curious without being technology-anxious. When something new appears — a new framework, a new rendering paradigm, a new state management approach — I ask what problem it's solving and whether that problem looks familiar. It usually does. The implementation is new. The problem isn't.

I also try not to treat framework transitions as mandatory upgrades. Sometimes the boring, established choice is genuinely the right one. The best codebase I ever worked in wasn't the most technically interesting one. It was the one where the decisions were clear, the boundaries were honest, and everyone working on it could hold the system in their head. That's a product of thinking, not tooling.