4 ms·

Having to refresh the page every time you make a change or open a modal is a terrible user experience.

sidlls 5y ago
Watching widgets/components freeze after an interaction because of a poorly-handled race condition in the JavaScript, dropped or mis-handled/scheduled async requests, and inconsistent cross-component state management isn't any better. It's arguably worse, because now the user has to guess as to whether something is wrong with the application or not and then refresh anyway.
bingo-bongo 5y ago
What makes it a terrible user experience?
YuukiRey 5y ago
https://sr.ht/ https://sr.ht/ is faster than most SPAs I know and it refreshes the page a lot
- gefhfffh 5y ago
  It's not faster despite being in WiFi
GordonS 5y ago
This is trivial with a sprinkling of JavaScript - our pages do update as required after form POSTs, for example.
hackerfromthefu 5y ago
Nonsense :)
spoils19 5y ago
Users don't really know what they want, and I'd wager that most are willing to accept a page refresh if they understood the immense productivity gains that developers like achieve, for a worse "user experience".
- orange8 5y ago
  > Users don't really know what they want Users do not care about "immense developer productivity"
stepbeek 5y ago
This is a false-dichotomy/straw man. The conversation is about a javascript-heavy approach being overkill. I haven’t seen many arguing for noscript here. Implementing a form that autosubmits and updates an element takes very little js.
Uristqwerty 5y ago
You can replace a chunk of innerHTML faster than a full page reload, using a near-trivial piece of vanilla JS. But a full page reload also clears out memory "leaks", old state accidentally kept around in caches, clinging to DOM nodes discarded long ago, but themselves still referenced by an old copy of a data structure, etc. If you go for a SPA, or even something in between, suddenly being careful about your data structures becomes a major concern to long-term app use, carrying a whole new category of debugging.

Watching widgets/components freeze after an interaction because of a poorly-handled race condition in the JavaScript, dropped or mis-handled/scheduled async requests, and inconsistent cross-component state management isn't any better. It's arguably worse, because now the user has to guess as to whether something is wrong with the application or not and then refresh anyway.

bingo-bongo 5y ago

What makes it a terrible user experience?

YuukiRey 5y ago

https://sr.ht/ https://sr.ht/ is faster than most SPAs I know and it refreshes the page a lot

gefhfffh 5y ago
It's not faster despite being in WiFi

GordonS 5y ago

This is trivial with a sprinkling of JavaScript - our pages do update as required after form POSTs, for example.

hackerfromthefu 5y ago

Nonsense :)

spoils19 5y ago

Users don't really know what they want, and I'd wager that most are willing to accept a page refresh if they understood the immense productivity gains that developers like achieve, for a worse "user experience".

orange8 5y ago
> Users don't really know what they want Users do not care about "immense developer productivity"

stepbeek 5y ago

This is a false-dichotomy/straw man. The conversation is about a javascript-heavy approach being overkill. I haven’t seen many arguing for noscript here. Implementing a form that autosubmits and updates an element takes very little js.

Uristqwerty 5y ago

You can replace a chunk of innerHTML faster than a full page reload, using a near-trivial piece of vanilla JS. But a full page reload also clears out memory "leaks", old state accidentally kept around in caches, clinging to DOM nodes discarded long ago, but themselves still referenced by an old copy of a data structure, etc. If you go for a SPA, or even something in between, suddenly being careful about your data structures becomes a major concern to long-term app use, carrying a whole new category of debugging.