single-page application

From IndieWeb

A single-page application (SPA) is a web application or web site that fits on a single web page with the goal of providing a user experience similar to that of a desktop application. A typical use case for implementing a SPA would be for a PWA where an app-like feel is intended with instant transitions between views/pages.

Use-cases

  • continuous uninterrupted seamless video conferencing even when navigating across "pages" on the same site

Instead

Criticism

General

  • 2022-02-22 Chris Ferdinandi: SPAs were a mistake (archived)
  • https://twitter.com/simonw/status/1499137212234956802
  • https://twitter.com/craigkerstiens/status/1499150435118026752
    • "We rebuilt our entire frontend for Crunchy Bridge from ground up, threw out SPA, all request response traditional now... velocity is better, product is more polished, quality is better. Not sure there was a downside." @craigkerstiens March 2, 2022
    • expanding upon simonw's tweet above: https://news.ycombinator.com/item?id=30533473
      • "It's been so frustrating watch this play out over the past decade.
        I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs.
        Inevitably none of these projects end up taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states, and the "interactivity" mainly consists of form submissions that don't trigger a full page - which could have been done for a fraction of the cost (in development time and performance) using a 2009-era jQuery plugin!
        And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons.
        I started out thinking "surely there are benefits to this approach that I've not understood yet - there's no way the entire industry would swing in this direction if it didn't have good reasons to do so".
        I've run out of patience now. Not only do we not seem to be learning from our mistakes, but we've now trained up an entire new generation of web developers who don't even know HOW to build interactive web products without going the SPA route!
        My recommendation remains the same: default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit.
        Don't default to building an SPA." @simonw March 2, 2022
  • Criticism: https://twitter.com/slightlylate/status/1567184926038183938
    • "Upcoming conference talks have me once again thinking about the ways in which the frontend community has entirely lost the plot.

      Until and unless you have hard data of long sessions with many "fiddly" interactions, your content should *not* be an "SPA" or JS-first." @slightlylate September 6, 2022

Blank screen failures

Some SPAs fail with blank screens: https://twitter.com/zachleat/status/1394005631267483652

  • "Naming party: what do you call the thing when your SPA fails with a blank screen?" @zachleat May 16, 2021

Fails with disabled JS

Inefficient

Breaks browser back button

Often unnecessary

See Also

  • js;dr
  • Use-case: PeerTube - a video sharing portal where you seed back content that you consume to make it scale without the operator being Big Tech. If it reloaded the page after every search, play or comment, it would need to rebuild all of its peer connections and flush all of its caches from RAM. Various web applications could be implemented similarly that mandate hosting either huge items or a vast amount of items: wiki, photo sharing, social networking