[morrvs]

True, we should respect all the resources of a device, at best. Also true for desktop (Slack's memory usage comes to mind).

A major result of the study is greatly reduced bandwidth (and consequently, shorter parse time) compared to the original TeuxDeux, so I'm working towards respecting these resources, for what it's worth.

To be clear, the study does not care about doing SPAs or not. The results are applicable to server-rendered HTML as well (write a function that enable some behavior on an element, mount by class name, done). I agree that many use cases (e.g. blogs) should mostly be server-rendered and only progressively enhanced with JS for some UX improvements.

But highly interactive apps (drag & drop just being one example) will not have comparable UX without client-side rendering. I do not want a 100-1000ms delay (or an error message) after dropping an item in some list because of a server-roundtrip. This is not good UX.

Also, when filling out a form, I do not want to lose data or context when clicking submit while I'm in a tunnel. I'd rather have a client-side rendered UI that keeps my context and tells me "Sorry, try again when you're connected again".

Even better if it works fully offline and syncs the transactions I've done with a backend once I'm connected again.

[falcolas]

A small note: 100ms is effectively imperceptible to a human. Even 1s is acceptable in most cases. There’s a HCI study from the late 60’s that defines this.

WRT losing data by filling out a form, that hasn’t been an issue for years now (except when the “smart client renderer” decides that it is). Most browsers will not lose data in an interrupted form transmission.

Plus, most browsers (especially mobile ones) handle interruptions like a tunnel fairly well, waiting for the connection to return without losing data. And without having to think about that usecase as a web developer.

It’s funny to me that you mentioned slack above; some of my favorite old-school chat experiences were server-side rendered pages. They worked remarkably well for the limitations they faced.

All this said, the proper compromise is probably doing both client and server-side rendering. I’m reflexively against client side rendering, because of how they’re typically implemented: slow to download up front, each SPA creates its own interaction primitives, and finally the interactivity of an SPA is only rarely required and yet they’re used everywhere (read-only SPAs are the worst).

Javascript - and client-side rendering - is the power hammer of the frontend development world.

[morrvs]

Not sure about the interruption handling, maybe I need to do more research there.

But totally agree with the last parts - currently, typical SPA implementations are often misguided and create more problems than they solve (if any) compared to a server-side approach. That does not mean that pure server-side is always enough to provide good UX, especially with interactive/offline apps.

[astura]

In theory.

In the real world my crusty old-fashioned drag-and-drop works way better than pretty much all "SPA"s (who are only trying to display plain text) on low/spotty connection. SPAs usually fail to display anything but a blank screen when there is a slow connection.

Losing form data hasn't been an issue in forever... The browser saves it when you go back or forward. You don't even need to press "back" - you can even just refresh the error page and as long as you click "yes" to the pop-up telling you you're resubmitting a POST, the form will submit with the original data entered, no problem.... Of course, SPAs like to break this for no reason, stop doing that.