Thoughts on design, code, and the intersection of technology and humans.
Not productivity metrics or hype. Just an honest account of what shifted, what didn't, and the part nobody talks about: what it did to how I think.
Moving from Pages Router to App Router isn't a refactor. It's a different way of thinking about your entire application. The technical parts were the easy part.
The technology choice matters less than the team structure it implies. Most teams pick the wrong tool because they're solving a technical problem that's actually organizational.
Three years into building production UIs with Tailwind, the utility-first debate feels less interesting than what the approach actually changed about how I reason about styling.
I've seen fast codebases that look messy and slow codebases that look clean. The difference was never the code quality. It was who felt responsible for which decisions.
Signals aren't new, but their moment in the frontend mainstream is arriving. Understanding why they're compelling — and what they'd cost — is becoming a relevant skill.
Monorepos solve real problems at scale. They also introduce new ones. The teams that get the most out of them are the ones who were specific about which problem they were solving.
Most teams blame the component library when their design system collapses. The real problem is almost always somewhere else entirely.
Frontend performance isn't about squeezing milliseconds from your render cycle. It's about rethinking what you're actually sending to the browser — and why.
A large portion of the state management complexity in React apps isn't really state management — it's server cache management pretending to be state.
Building accessible interfaces makes you a better frontend engineer — not because it's the right thing to do, but because it forces you to understand how the web actually works.
After years of TypeScript in production React codebases, the patterns worth keeping are the ones that reduce decisions, not the ones that demonstrate type-level cleverness.
Most janky animations in production have the same root cause: work happening on the main thread that should happen on the compositor. Understanding why fixes the whole class of problems.
Most testing advice for frontend teams either tests too much at the wrong level or ignores the things users actually care about. Here's what works in practice.
It's not just a new feature. It's a mental model shift that has been brewing for years, and many teams still don't fully grasp it.
