Do We Really Need Single‑Page Applications?

The web development ecosystem has seen a massive shift over the past decade. With React, Angular, Vue, Node.js, Bun and friends, Single‑Page Applications suddenly became the default choice for a lot of developers. The promise was simple: better performance, richer interactivity, and a more “app‑like” experience on the web.

On the other hand, PHP - a language many people casually call outdated - still powers over 70% of the surface web. That alone should make us pause. If the “old” thing still runs most of the internet, did we really need to rebuild everything as SPAs? Or did we just follow the hype?
This article digs into that question. How SPAs rose. Why PHP never left. What actually changed. And whether SPAs are truly necessary for most of what we build on the web today.

---

1. How SPAs took over

For a long time, the web worked in a very straightforward way. You clicked a link, the server rendered a page, the browser showed it. Every interaction meant a full page reload. For simple sites, that was fine. For complex apps, it started to feel slow and clunky.

Then SPAs came in.

Instead of reloading the whole page, the browser would fetch data and update only parts of the UI. No full reload. Just smooth transitions. It felt modern. It felt like a native app. React, Angular, Vue made this style of development accessible and even fun. Node.js made it possible to write JavaScript on both frontend and backend. “JavaScript everywhere” became the slogan.

Developers loved it. Component‑based UIs. Client‑side routing. State management. All the buzzwords. It wasn’t just a technical shift. It was a cultural one. If you weren’t using a SPA framework, you were “behind”.

But under all that excitement, some cracks were already visible.

---

2. The hidden cost of SPAs

SPAs did solve a real problem: they made complex, interactive interfaces feel smoother. But they also introduced a new kind of heaviness.
Instead of the server doing most of the work, the browser now had to download big JavaScript bundles, parse them, execute them, and then “hydrate” the UI. Before the user could even interact with anything, a lot of JS had to run. On a powerful machine with fast internet, this might feel okay. On a low‑end phone with spotty network? Not so much.

SEO became trickier. Accessibility often took a back seat. Routing moved to the client. State had to be managed manually. Build tools, bundlers, transpilers, linters, formatters - the stack kept growing. To build even a relatively simple site, you suddenly needed a full pipeline.
The mental load increased too. It wasn’t just “learn a language and a framework”. It became “learn React, then learn hooks, then learn a state library, then learn a router, then learn the build system, then learn how to deploy it”. The web got more powerful, yes. But also more complex than many projects actually needed.

---

3. PHP: the quiet king that never left

While all this was happening, PHP just kept doing its job.

WordPress , Drupal , Joomla , phpBB, MyBB, Laravel , Magento - all of these and more are built on PHP. Together, they still power the majority of the web. That’s not nostalgia. That’s reality.

PHP is simple to deploy. You drop files on a server, configure a virtual host, done. Hosting is cheap. The ecosystem is mature. The synchronous model is easy to reason about. You don’t need a separate build step just to see HTML in the browser.

And PHP itself has evolved. PHP 8+ brought serious performance improvements. JIT. OPcache. Fibers. Frameworks like Laravel and Symfony made modern, clean application architecture the norm. Tools like Laravel Octane, RoadRunner, Swoole pushed PHP into high‑performance territory that many people still assume only Node can handle.

So when someone says “PHP is outdated”, it’s usually not based on what PHP actually is today. It’s based on an old image that never got updated.

---

4. Can we live without SPAs?

Short answer: Yes. The web already does.

Most websites do not need SPA‑level complexity. Blogs. Forums. News sites. Documentation. Corporate sites. Marketing pages. Even a lot of admin panels and dashboards. These work perfectly fine - often better - as server‑rendered applications.

In these cases, SPAs are not just unnecessary. They can be a net negative. Slower first load. More JavaScript. More moving parts. More things to break. And for what? A bit of “smoothness” that could often be achieved with small, targeted sprinkles of JavaScript instead of a full SPA architecture.
SPAs shine in a different category. Think Gmail, Figma, Trello, Notion. Real‑time collaboration. Heavy client‑side state. Offline support. Multi‑pane interfaces. These are genuine web applications, not just websites. For this kind of product, SPA‑style architecture makes sense.

But that’s the point. SPAs are great for applications. Not everything on the web is an application.

---

5. The pendulum swings back to the server

The interesting thing is this: even the SPA world is now moving back toward the server.

React is pushing Server Components. Next.js leans heavily on server‑side rendering and streaming. Remix focuses on server‑first data loading. Astro and Qwik talk about shipping less JavaScript and hydrating only what’s needed. SvelteKit embraces server rendering as a first‑class citizen.
The message is clear. We went too far with “everything must be a SPA”. Now the industry is correcting itself.

Server‑first rendering gives faster initial load, better SEO, simpler mental models, and less JavaScript shipped to the client. It also respects users on low‑end devices and slow networks. Instead of forcing the browser to do all the heavy lifting, we let the server do what it’s good at.

In that world, PHP fits naturally. It has always been server‑first.

---

6. What SPAs really did: moved the load

If we strip away the hype, SPAs did one big thing: they moved the load.

Before SPAs, the server rendered HTML. The browser displayed it. JavaScript was there, but as a helper. The heavy work stayed on the server.
After SPAs, the browser became the main worker. It had to parse JS, execute it, manage state, handle routing, and render the UI. The server mostly turned into an API that just sent JSON.

This shift made sense for some use cases. But as a default for everything? It made the web heavier, more fragile, and less inclusive.

Not everyone has a flagship phone. Not everyone has fiber internet. Not everyone has a powerful laptop. When we push more and more work to the client, we silently exclude a lot of people.

---

7. The future: hybrid, server‑first, and boring in a good way

The future of the web doesn’t look like “SPA vs PHP”. It looks more like “use the server by default, add JavaScript where it actually matters”.
Server‑rendered HTML as the baseline. Small interactive islands where needed. Partial hydration. Edge rendering for speed. Progressive enhancement so the core experience works even if JS fails.

This approach is not flashy. It’s not the kind of thing that gets you a shiny new framework logo on your portfolio. But it’s fast. It’s robust. It’s maintainable. And it respects users.

PHP fits into this future very well. It’s already optimized for server‑rendered flows. It’s battle‑tested. It’s everywhere. And with modern PHP and frameworks, you can still build clean, modular, maintainable systems without dragging in unnecessary complexity.

---

So, did the web truly need SPAs? For some things, yes. For most things, no.

SPAs are a powerful tool. They make sense for complex, highly interactive applications. But they were never meant to be the default for every blog, every landing page, every forum, every store.

PHP, on the other hand, quietly kept doing the work. Powering the majority of the web. Evolving. Getting faster. Staying simple where simplicity is a strength, not a weakness.

The real answer is not “SPA vs PHP”. It’s “pick the right tool for the job”. And if the job is a typical website, a content‑driven platform, or even a lot of internal tools, a server‑rendered architecture - often powered by PHP - is still the most sensible choice.