Why Most Websites Didn’t Need Single-Page Apps
I observed a curious pattern in web development over the past decade: the adoption of single-page applications grew exponentially while the problems they solved remained narrowly scoped.
Most websites pursuing SPA architectures were solving for an audience that didn't exist.
Single-page applications (SPAs) introduced substantial complexity — build pipelines, state management, API contracts, hydration concerns, and JavaScript bundle optimization.
This overhead was justified only when a site's interactivity demanded instant state synchronization and persistent UI. For the majority of websites, these requirements were theoretical rather than actual.
Performance Regression
SPAs shifted rendering responsibility to the client. On low-end devices and constrained networks, this translated directly to degraded Time to Interactive, blank screen periods, and heavy JavaScript parsing costs.
Server-rendered pages delivered meaningful content on first response. The performance inversion was pronounced: architectures promoted as modern often performed worse than the approach they replaced.
Search, Discoverability, Accessibility and Navigation
Client-side rendering introduced indexation uncertainty. Search engines improved their JavaScript execution over time, but inconsistently.
Content-heavy sites — documentation, publishing, ecommerce — surrendered indexation reliability in exchange for interactivity that their users never demanded. The tradeoff was asymmetric.
Browser-native navigation behaviors — history management, scroll restoration, focus handling — required manual reimplementation inside SPAs.
Screen readers relied on document lifecycle events that client-side routing disrupted. Teams routinely discovered these gaps late, after the architecture was already committed.
Maintenance Surface
JavaScript ecosystems moved rapidly. SPA projects accumulated dependency debt, required periodic framework migrations, and demanded frontend specialization that smaller teams lacked. Server-rendered applications maintained substantially longer stability windows with fewer external dependencies.
Where SPAs Made Sense
The legitimate domain remained narrow: collaborative tools, real-time interfaces, and applications treating the browser as a persistent runtime rather than a document viewer. These cases justified the architectural cost. Most websites didn't qualify.
Technology choices compound across a project's lifetime. Matching architecture to actual problem domain — rather than to industry momentum — remained the more durable principle.