single-page application

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

 * alternative: plain static HTML: https://twitter.com/kornelski/status/1280161347066630151
 * "The really cool thing is that when HTML is delivered fast enough, there's no flash of partial page. It looks and feels like a single-page app, with none of the complexity." @kornelski July 6, 2020

General

 * Followed the next day by:
 * https://twitter.com/simonw/status/1499137212234956802
 * "Couldn't resist the bait: I'm howling into the wind on Hacker News today about how defaulting to SPAs is a bad idea and we should stop doing that https://news.ycombinator.com/item?id=30533473" @simonw March 2, 2022
 * 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
 * "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

 * Criticisms: https://chat.indieweb.org/dev/2023-06-02/1685721693927800
 * "Doesn't work with disabled js" [ @vladimyr] June 2, 2023
 * Most SPAs are js;dr

Inefficient

 * Criticisms: https://chat.indieweb.org/dev/2023-06-02/1685721693927800
 * "transfers way more bytes over the wire than it is usually necessarily" [ @vladimyr] June 2, 2023

Breaks browser back button

 * Criticisms: https://chat.indieweb.org/dev/2023-06-02/1685721693927800
 * "often breaks back button" [ @vladimyr] June 2, 2023

Often unnecessary

 * Criticisms: https://chat.indieweb.org/dev/2023-06-02/1685721693927800
 * "and at the end of day not everything needs to be an app" [ @vladimyr] June 2, 2023