I like React. I've shipped projects with it and I'll ship more. It's well-designed, widely supported, and genuinely the right tool for certain problems — complex interactive UIs, real-time data, native mobile apps. When the project calls for it, I reach for it without hesitation.
But not every project calls for it, and knowing the difference is one of the more valuable things 20+ years of building gives you.
The way I think about every project
Three things drive how I make technology decisions: speed, simplicity, and stability. Speed in how fast the end product performs and how efficiently it gets built. Simplicity in the codebase — something the next developer (or future me) can understand and maintain without a roadmap. Stability in the dependency footprint — fewer moving parts means fewer things to break over time.
Those three objectives point toward the right tool more reliably than any trend does.
What modern JavaScript brings to the table
Plain JavaScript in 2026 is not what it was ten or fifteen years ago. The DOM APIs are clean and well-supported. Fetch handles API calls without a library. Routing, validation, dynamic content updates — a large portion of what used to require a framework can be done today with straightforward, readable vanilla JS and zero build step.
The result loads faster, has a smaller dependency surface, and can be picked up by any developer who knows JavaScript — which is just about everyone. For complex websites, database-driven interfaces, CMS builds, and API integrations, this approach often hits all three of my objectives better than a framework would.
When React is the right call
React earns its place when the problem is genuinely complex — a UI with many interconnected components that share state and update in real time, a full single-page application, a React Native mobile app. These are situations where the structure React provides pays for itself quickly and the alternative would be reinventing that structure in vanilla JS anyway.
The signal I look for is state complexity. If I'm managing lots of moving parts that depend on each other and need to stay synchronized across the UI, React is the right call. If I'm making things happen when a user clicks something, modern JavaScript handles that cleanly and with less overhead.
The skill is knowing which is which
The best developers I've worked alongside over the years aren't the ones who know the most frameworks — they're the ones who can look at a project and know which tool gets it built fastest, keeps it simplest, and leaves it most stable for whoever touches it next.
React is a great tool. So is plain JavaScript. Using them in the right situations is the point.
