I've worked on enough frontend codebases to have real opinions about this. The JavaScript framework ecosystem is genuinely impressive React, Vue, Svelte, Astro, Next, Nuxt, the list doesn't end, but there's a pattern I keep seeing that I find genuinely frustrating: teams reaching for a full SPA framework before they've asked whether they actually need one.
This isn't a framework-bashing post. React is great. Vue is great. The problem is the reflex, not the tools themselves.
When a marketing site becomes a React app for no reason
Picture a five-page company website. Static content, a contact form, maybe a few scroll animations. No user authentication, no real-time data, no complex state to manage. And yet it's built as a full React SPA with client-side routing, a 400KB JavaScript bundle, and a first meaningful paint that takes three seconds on a decent connection.
Why? Usually because the dev team knew React, the project kicked off with a create-react-app starter, and nobody stopped to ask whether this particular site actually warranted the overhead. The framework became the default, not a considered choice.
Teams at Mittal Technologies encounter this regularly in audit work, sites that are technically sophisticated but perform worse than a well-written HTML/CSS page would have, purely because of unnecessary JavaScript weight that nobody questioned at the architecture stage.
The real cost: performance, SEO, and developer experience
JavaScript is expensive to parse. That 200KB bundle isn't just 200KB of download, it's 200KB that the browser has to download, parse, compile, and execute before users see anything interactive. On a mid-range Android device (which represents most of the world's real web traffic), this isn't a theoretical concern. It's a meaningful delay that affects real users.
Then there's SEO. Googlebot handles JavaScript. Yes, but with documented delays and occasional rendering failures. A content-heavy site that requires JavaScript to render its primary content will always have weaker crawl coverage than one that serves HTML directly. That's not an opinion, it's observable behavior.
The alternative isn't "no framework", it's the right tool for the context
Astro changed how I think about this. The islands architecture model where most of the page is static HTML but interactive components hydrate individually only where needed, is the right mental model for most content-heavy sites. You get component-based developer experience without shipping a full SPA runtime to every user.
For highly interactive applications, dashboards, collaborative editors, real-time tools, a full client-side framework makes complete sense. The mismatch is when that same architecture gets applied to a blog, a landing page, or a documentation site. The complexity doesn't serve anyone.
Three questions to ask before picking a framework
I now try to honestly answer three questions before committing to a framework on any new project: Does this UI have a complex, interdependent state that genuinely needs managing? Will users interact with it in ways that require real client-side reactivity? Is this project going to grow into something where a component ecosystem actually matters long-term?
If the answer to all three is no or even mostly no, the simplest tool that can do the job is almost always the right choice. Your users will feel the performance difference. Search engines will notice it. And six months from now, the developer who inherits the codebase will appreciate not having to wrangle a full SPA for what is, at its core, a brochure site.
Top comments (0)