The Case Against SPAs in 2026 | Arjun.

People find this funny. A frontend engineer's portfolio with no frontend framework. But after years of building SPAs, I think the funnier thing is how rarely we ask whether we actually need one. ... At some point in the last decade, SPAs stopped being a technical choice and became the default. Junior devs spin up Next.js for a three-page portfolio. Agencies scaffold React apps for marketing sites. I've seen Gatsby projects for restaurant menus. A landing page that should be 4 KB of HTML ships as a 300 KB JavaScript bundle with a loading spinner. … ## Problems you didn't have before SPAs create entire categories of problems that plain websites don't have. Client-side routing means managing browser history and the back button. State management means context, reducers, or a store. Code splitting means loading states for every route. SSR means hydration mismatches that only reproduce in production and make you question your career choices. I deal with all of this at work. It's worth it there. But when the thing you're building is a portfolio or a blog - content that doesn't change between requests - you've imported all that complexity to serve static text. … If your app has state that changes frequently based on user interaction. If users expect instant navigation and optimistic updates. If twenty developers need to build consistent UIs from a shared component library. If your content comes from APIs and changes hourly. Those are real SPA problems with real SPA solutions. The mistake isn't using React for a SaaS dashboard. It's using React for a portfolio. It's reaching for the same tool regardless of the problem because it's the tool you know.