6 ms·

> These apps [single page web applications] also tend to feel snappier because page loads are not required for every request. This isn't my experience at all,

> These apps [single page web applications] also tend to feel snappier because page loads are not required for every request. This isn't my experience at all, especially when network conditions are not great. The browsers has error handling and a progress bar. Single page web applications often have bad or no error handling and you have no idea if the request failed, the code errored or something else went wrong. You need to refresh the whole page if something goes wrong, which results in having to load a ton of JS every again, negating all possible savings in time and data usage.

ducktective 5y ago
Exactly. The only time I felt the supposed "snappiness" is for documentation websites (so mainly text) that pre-fetch all links.
unlimit 5y ago
I agree and I hate two things about SPAs. - Works terrible in bad networks. - And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue.
- GrumpyNl 5y ago
  "- And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue." Thats just bad design.
  - unlimit 5y ago
    I suspected that too, but I do not know enough about these reactive frameworks to be 100% sure. But as a user of such apps, it is absolutely frustrating.
    - Normal_gaussian 5y ago
      To stop jumping you need to explicitly size yet-to-load sections. Without JS this means giving images explicit sizing, with JS this means any section can be dynamically loaded and, therefore, jump. So good design takes into account dynamic loading and places size bounds accordingly. Reactive libraries/frameworks don't explicitly make this worse or better, except their presence implies a high chance of dynamic loading and, therefore, more opportunity for bad design. In addition most component libraries fail to communicate /who/ needs to size a component and if it is ever dynamic. It really doesn't help that most 'official' examples fail to resolve these issues.
  - jeffreygoesto 5y ago
    So at least in this aspect, bad design sense to have gotten a lot easier.
  - pc86 5y ago
    Something endemic to SPAs.
- capableweb 5y ago
  As is common when people rant about SPAs, your dislike (at least as written here) is not actually about SPAs but other things > Works terrible in bad networks Yes, software traditionally works shitty under bad network conditions unless the developer actively tests under bad network conditions or has previous experience of handling bad network conditions. This is as much true for anything developed ever that touches a network. > the shifting of images This is simply developers missing to add width and height attributes to their <img/> elements. This has been happening since the dawn of the <img/> element and is unlikely to disappear. Also has nothing to do with SPAs, same happens with server-rendered HTML.
  - jbverschoor 5y ago
    > unless the developer actively tests under bad network conditions > This is simply developers missing That's the whole thing. SPA = state. It requires a lot of dev time to properly handle everything. With stateless applications, you can simply refresh your browser. The sluggishness is not only because of bad network conditions, but it's multiplied by the huge application that has to be sent over the network, application initialization, and the many subsequent network requests.
    - hazz99 5y ago
      > The sluggishness is not only because of bad network conditions, but it's multiplied by the huge application that has to be sent over the network, application initialization, and the many subsequent network requests. A "huge" application can be broken up with code splitting/dynamic imports. Initialisation can be seeded with serverside data or saved in browser storage between pages. The only semi-unavoidable part is the "subsequent network requests", but even these can be sped up with caching, batching, etc. > It requires a lot of dev time to properly handle everything. But yeah, these things take effort
      - jbverschoor 5y ago
        The network requests could be done with more intelligent apis But if you take everything into account, you can also develop a really good native app. This is not reality.
- piokoch 5y ago
  "shifting of images" So much truth, not once I was trying to click on some image that had link underneath, and it suddenly moved to some other place and I ended clicking something different.
- tannhaeuser 5y ago
  A truly intolerable thing about SPAs and JavaScript is that regular HTTP caching of images and fonts had to be limited because JS APIs can be and are used for fingerprinting, driving the whole web thing ad absurdum. Switching off JS/fingerprinting doesn't really help either since it'll just disproportionally benefit Google's stronghold on web analytics even more.
  - IX-103 5y ago
    Fingerprinting is not just JS. Fingerprinting is possible just using CSS rules alone. The bigger issue, which seems to be what you are complaining about seems to be the gaping hole in privacy provided by 3rd party storage/resources. That is not a particular problem with SPAs, and can even be exploited without JavaScript. I'm not sure where you're coming from regarding Google and web analytics. When 3rd party storage is gone (or partitioned) it sounds like everyone would be on the same page in terms of what data they can collect.
BoxOfRain 5y ago
One of my real pet hates is software developers who assume everyone's running their software on an excellent internet connection. Badly written SPAs are the worst offenders but I also pretty much gave up on any sort of regular gaming because pushing these enormous 10-20 GB updates over a sluggish connection just became insufferable. Add that to the constant and shameless fleecing of customers that's apparently the norm now and the enjoyment to effort ratio is just too low to bother with.
- AnIdiotOnTheNet 5y ago
  > One of my real pet hates is software developers who assume everyone's running their software on an excellent internet connection. That could be said for a lot of assumptions developers make. Everyone has 32GB of ram, everyone has an SSD, everyone has an i7... It is an old problem, but like almost everything else in computing for some reason it seems to have become much worse since about 2010.
  - letitbeirie 5y ago
    The spread of capabilities is bigger now. In 2000 a developer might have been developing on a Pentium 3 with 128 MB of RAM, but they could reasonably expect their audience to be using at least a 486 with 16 MB of RAM because that was the minimum spec for IE4. Now you're stuck with trying to impress people with a Ryzen Threadripper and 64GB of DDR5, but your webapp still has to support everyone's iPhone 7 (with 2GB to share with iOS and everything else they have running) for as long as Apple does.
    - tompazourek 5y ago
      Apple still supports the older iPhones. For example, the iPhone 6 that doesn't get the latest iOS version anymore (stuck with iOS 12) is still supported by regular security updates (the last iOS 12 update was 54 days ago). Apple supports (at least security wise) probably more devices than you think.
    - jrumbut 5y ago
      What I think is even more different is that someone with the 486 in 2000 was used to the idea that they wouldn't be able to run some software, but unable to run a website? Unheard of, it's just broken.
deepstack 5y ago
> the code errored or something else went wrong. You need to refresh the whole page if something goes wrong, which results in having to load a ton of JS every again, negating all possible savings in time and data usage. Not to mention that some SPA doesn't maintain state, and all the sudden one need to jump through the the process all over again. Personally SPA seems to try reimplement a lot of browser feature all over again in client side JS.
philote 5y ago
I think it's just like anything that's gotten popular. SPAs are all over the place now, which means there are plenty of bad implementations along with the good ones. But generally you only notice the bad ones due to frustration. This isn't SPA-specific IMO. I've seen plenty of server rendered pages/sites that were also poorly done back when those were more the norm. Heck, I still help maintain a set of CGI scripts that are horrible and slow.
thejosh 5y ago
Yeah, especially when it's multiple sequential loads, so instead of a large HTML blob it takes forever. Usually with 270ms+ if it's US East (from Australia).
ajsnigrutin 5y ago
Infinite scroll pages are the worst with this.. You scroll and scroll, and scroll, and every time you reach some level "down", another section is loaded, then at one moment it stops. Something somewhere fails, no more new sections, no way to continue from that point, only a full refresh and a huge scroll down.
- Riverheart 5y ago
  Which wouldn't be nearly as bad if they gave you an offset parameter, or updated the offset parameter in the URL which they almost never do.
- SpelingBeeChamp 5y ago
  Hello Patreon.
slumdev 5y ago
Exactly. A flawless SPA backed by a flawless API that produces responses in tens of milliseconds is superior to the old ways. But a trash SPA backed by an API that produces responses eventually if ever and requires me to open the browser's developer tools to find out what happened? You can keep it. Old-school frameset sites are better than that.

ducktective 5y ago

Exactly. The only time I felt the supposed "snappiness" is for documentation websites (so mainly text) that pre-fetch all links.

unlimit 5y ago

I agree and I hate two things about SPAs. - Works terrible in bad networks. - And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue.

GrumpyNl 5y ago
"- And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue." Thats just bad design.
- unlimit 5y ago
  I suspected that too, but I do not know enough about these reactive frameworks to be 100% sure. But as a user of such apps, it is absolutely frustrating.
  - Normal_gaussian 5y ago
    To stop jumping you need to explicitly size yet-to-load sections. Without JS this means giving images explicit sizing, with JS this means any section can be dynamically loaded and, therefore, jump. So good design takes into account dynamic loading and places size bounds accordingly. Reactive libraries/frameworks don't explicitly make this worse or better, except their presence implies a high chance of dynamic loading and, therefore, more opportunity for bad design. In addition most component libraries fail to communicate /who/ needs to size a component and if it is ever dynamic. It really doesn't help that most 'official' examples fail to resolve these issues.
- jeffreygoesto 5y ago
  So at least in this aspect, bad design sense to have gotten a lot easier.
- pc86 5y ago
  Something endemic to SPAs.
capableweb 5y ago
As is common when people rant about SPAs, your dislike (at least as written here) is not actually about SPAs but other things > Works terrible in bad networks Yes, software traditionally works shitty under bad network conditions unless the developer actively tests under bad network conditions or has previous experience of handling bad network conditions. This is as much true for anything developed ever that touches a network. > the shifting of images This is simply developers missing to add width and height attributes to their <img/> elements. This has been happening since the dawn of the <img/> element and is unlikely to disappear. Also has nothing to do with SPAs, same happens with server-rendered HTML.
- jbverschoor 5y ago
  > unless the developer actively tests under bad network conditions > This is simply developers missing That's the whole thing. SPA = state. It requires a lot of dev time to properly handle everything. With stateless applications, you can simply refresh your browser. The sluggishness is not only because of bad network conditions, but it's multiplied by the huge application that has to be sent over the network, application initialization, and the many subsequent network requests.
  - hazz99 5y ago
    > The sluggishness is not only because of bad network conditions, but it's multiplied by the huge application that has to be sent over the network, application initialization, and the many subsequent network requests. A "huge" application can be broken up with code splitting/dynamic imports. Initialisation can be seeded with serverside data or saved in browser storage between pages. The only semi-unavoidable part is the "subsequent network requests", but even these can be sped up with caching, batching, etc. > It requires a lot of dev time to properly handle everything. But yeah, these things take effort
    - jbverschoor 5y ago
      The network requests could be done with more intelligent apis But if you take everything into account, you can also develop a really good native app. This is not reality.
piokoch 5y ago
"shifting of images" So much truth, not once I was trying to click on some image that had link underneath, and it suddenly moved to some other place and I ended clicking something different.
tannhaeuser 5y ago
A truly intolerable thing about SPAs and JavaScript is that regular HTTP caching of images and fonts had to be limited because JS APIs can be and are used for fingerprinting, driving the whole web thing ad absurdum. Switching off JS/fingerprinting doesn't really help either since it'll just disproportionally benefit Google's stronghold on web analytics even more.
- IX-103 5y ago
  Fingerprinting is not just JS. Fingerprinting is possible just using CSS rules alone. The bigger issue, which seems to be what you are complaining about seems to be the gaping hole in privacy provided by 3rd party storage/resources. That is not a particular problem with SPAs, and can even be exploited without JavaScript. I'm not sure where you're coming from regarding Google and web analytics. When 3rd party storage is gone (or partitioned) it sounds like everyone would be on the same page in terms of what data they can collect.

BoxOfRain 5y ago

One of my real pet hates is software developers who assume everyone's running their software on an excellent internet connection. Badly written SPAs are the worst offenders but I also pretty much gave up on any sort of regular gaming because pushing these enormous 10-20 GB updates over a sluggish connection just became insufferable. Add that to the constant and shameless fleecing of customers that's apparently the norm now and the enjoyment to effort ratio is just too low to bother with.

AnIdiotOnTheNet 5y ago
> One of my real pet hates is software developers who assume everyone's running their software on an excellent internet connection. That could be said for a lot of assumptions developers make. Everyone has 32GB of ram, everyone has an SSD, everyone has an i7... It is an old problem, but like almost everything else in computing for some reason it seems to have become much worse since about 2010.
- letitbeirie 5y ago
  The spread of capabilities is bigger now. In 2000 a developer might have been developing on a Pentium 3 with 128 MB of RAM, but they could reasonably expect their audience to be using at least a 486 with 16 MB of RAM because that was the minimum spec for IE4. Now you're stuck with trying to impress people with a Ryzen Threadripper and 64GB of DDR5, but your webapp still has to support everyone's iPhone 7 (with 2GB to share with iOS and everything else they have running) for as long as Apple does.
  - tompazourek 5y ago
    Apple still supports the older iPhones. For example, the iPhone 6 that doesn't get the latest iOS version anymore (stuck with iOS 12) is still supported by regular security updates (the last iOS 12 update was 54 days ago). Apple supports (at least security wise) probably more devices than you think.
  - jrumbut 5y ago
    What I think is even more different is that someone with the 486 in 2000 was used to the idea that they wouldn't be able to run some software, but unable to run a website? Unheard of, it's just broken.

deepstack 5y ago

> the code errored or something else went wrong. You need to refresh the whole page if something goes wrong, which results in having to load a ton of JS every again, negating all possible savings in time and data usage. Not to mention that some SPA doesn't maintain state, and all the sudden one need to jump through the the process all over again. Personally SPA seems to try reimplement a lot of browser feature all over again in client side JS.

philote 5y ago

I think it's just like anything that's gotten popular. SPAs are all over the place now, which means there are plenty of bad implementations along with the good ones. But generally you only notice the bad ones due to frustration. This isn't SPA-specific IMO. I've seen plenty of server rendered pages/sites that were also poorly done back when those were more the norm. Heck, I still help maintain a set of CGI scripts that are horrible and slow.

thejosh 5y ago

Yeah, especially when it's multiple sequential loads, so instead of a large HTML blob it takes forever. Usually with 270ms+ if it's US East (from Australia).

ajsnigrutin 5y ago

Infinite scroll pages are the worst with this.. You scroll and scroll, and scroll, and every time you reach some level "down", another section is loaded, then at one moment it stops. Something somewhere fails, no more new sections, no way to continue from that point, only a full refresh and a huge scroll down.

Riverheart 5y ago
Which wouldn't be nearly as bad if they gave you an offset parameter, or updated the offset parameter in the URL which they almost never do.
SpelingBeeChamp 5y ago
Hello Patreon.

slumdev 5y ago

Exactly. A flawless SPA backed by a flawless API that produces responses in tens of milliseconds is superior to the old ways. But a trash SPA backed by an API that produces responses eventually if ever and requires me to open the browser's developer tools to find out what happened? You can keep it. Old-school frameset sites are better than that.