7 ms·

Some people don't seem to understand what the whole JS SPA thing is about, and it's quite strange to me. It's not popular because it's a fad, it's not about re

Some people don't seem to understand what the whole JS SPA thing is about, and it's quite strange to me. It's not popular because it's a fad, it's not about replacing good old static websites with fancy over-engineered JS code. It's about making desktop-class applications more accessible via the web. Desktop-class Apps have lower latency requirements then server rendered frameworks are capable of delivering, plain and simple. You could certainly build Facebook as a fully server-rendered PHP app, but that would hurt Facebook's business because its servers would need to do more work and its users would have to wait longer for content. Fully server-rendered frameworks are not capable of delivering low-latency desktop-class applications. If your app doesn't require low-latency updates, then you can certainly use a classic PHP or Ruby on Rails stack with no problem. Sure, you can use JQuery style code to make your PHP app more interactive, but you're probably just going to end up with a messy, hard to understand JS code base eventually if you you don't have some sort of low-latency client-side declarative templating framework. There's certainly some companies that are caught in the hype and build a SPA app when they would probably be better served with a simple PHP site, but on every project I've worked on that used React across a few companies (interactive apps for ex: cropping & manipulating images, building visualizations and reporting on data), not using an SPA framework would have slowed down development dramatically, or left us with a really poor product.

asddubs 6y ago
IMO you can have your cake and eat it too - just offer a fallback of some sort, it's good SEO anyway. I haven't done anything in react but it's my understanding that this is actually possible to do, have react deliver an initial pre-rendered page and then still have your fancy SPA on top of it
pkage 6y ago
HN gets frothing mad about javascript, and to some extent I agree: sites that are fundamentally about content (news websites, blogs, etc.) should not be locked behind JS gates. The amount of code bloat on those pages tends to be related to tracking and advertising, so not running JS on those pages makes sense. On the other hand, web applications that provide full-featured experiences are only possible because of the full spectrum of web technologies. Choosing not to run JS and claiming that Google Docs should work without JS is ridiculous.
- resynth1943 6y ago
  Aside: outline.com is useful for news websites which require JavaScript.
  - dredmorbius 6y ago
    Many but by no means all. I increasingly rely on either Internet Archive's Wayback Machine (which also fails remarcably often to fully, or even partially, present SPAs), or Archive.today (archive.is, archive.fo, and friends), which is painfully slow to acquire content but does manage to render most it attempts.
- mixmastamyk 6y ago
  It’s almost as if you should pick the right tool for the job. ;-)
  - nicbou 6y ago
    We all agree on that. I just suspect that Hacker News only knows about two jobs: massively distributed applications and their static blog. In the middle, you have countless SPAs, but also slightly interactive websites that are 90% content, and 10% calculators/maps/widgets.
    - kyawzazaw 6y ago
      feel so true
    - ehutch79 6y ago
      It's not like those widgets need a full routing system with ssr, etc. Even with vue, you can just drop that component on the page.
      - RussianCow 6y ago
        But add enough of those widgets to a page, and now you need to coordinate local state, sync it with the URL, etc, which is way easier to do when the whole page is a SPA.
aboringusername 6y ago
> It's about making desktop-class applications more accessible via the web. I am not sure what "web" you're using, but as someone who uses noscript and has been enabling scripts for over a year now, I can firmly say JS is NOT used for making "desktop-class applications more accessible". It's used for ads. And spying. Lots and lots of spying. Seriously. Googletagmanager/analytics is everywhere, it doesn't deserve to be, it doesn't need to be. That domain needs to die a painful, horrible death. facebook, twitter, sessioncam, and many others are used to bloat pages, increase my energy usage, decrease my battery quicker and contribute to the wastage of energy on an unprecedented scale. Just ask yourself, how much money, battery life, bandwidth is spent every year on downloading useless scripts that as far as I can see offer no value whatsoever. By selectively deciding what scripts to enable I get the folliowing result: 1: pages are lighter, less bloated, and STILL WORK 2: I download less scripts, use less battery and save bandwidth and energy for myself and all humanity. 3: There is less spying as fetch() requests are blocked and there can be hundreds of them across a single web-page session (you can watch really bloated pages for 10 minutes, there can be 100's of requests easily). Test: load the following two pages, study their usage, test each with JS enabled/disabled: 1: https://old.reddit.com https://old.reddit.com (with JS:2.69, without: 2.34mb) 2: https://reddit.com https://reddit.com (with JS: 8.58mb, without: 8.10kb, but the page is broken...) Baring in mind old.reddit works fine with JS disabled, showing JS is not needed for a site like reddit to work at all. Yet, "web developers" use them as if it's nothing. Pages that execute over seconds, possibly MB's of data, all the additional requests that are made to enrich the likes of FB/Google et al. So no, SPA are a scam and the web is worse today than I remember back in the 2000's, at least we didn't have cookie pop up boxes because people can't help but abuse JS. Most of the GDPR violations I've found thus far are from scripts that have no place or purpose, that slurp up user data without remorse, that, if disabled, doesn't impact the functionality of the page, and that enables the great surveillance capitalism and data-raping we are seeing today.
- cellar_door 6y ago
  Ok, so you want to disable tracking and ads. Why does that necessitate disabling all JS? You can enjoy the performance of an SPA while selectively disabling tracking.
h_anna_h 6y ago
> its servers would need to do more work So far I have seen no evidence that this would be the case (rather, I have reasons to believe the contrary). > and its users would have to wait longer for content. They would actually have to wait less. Recently two of the sites that I used to use switched to react. I was able to have open literally 100s of tabs with them, each of them loading almost instantly (excluding media). Now I can barely hold 2 open and they load slowly (even if we ignore the time that it takes to load the media).
wyager 6y ago
> Fully server-rendered frameworks are not capable of delivering low-latency desktop-class applications Evidently, neither is JavaScript.
shadowgovt 6y ago
To a first approximation, you can do all your heavy-cpu computation on the server and have the client be a close-to-dumb terminal or you can have the server do some preprocessing and the client do some postprocessing. One spreads the load over CPUs better.
- TeMPOraL 6y ago
  > One spreads the load over CPUs better. Better for companies running high-powered servers with economic benefits of scale, or for users running low-end devices? This is just dumping an externality. Also, arguably, most performance issues of SPAs don't come from business-relevant calculations being slow. It comes from scaffolding, gratuitous, and bunch of other overhead that would not happen at all, server-side.
  - shadowgovt 6y ago
    The end user is also often paying for bandwidth, and doing local computation locally saves that cost.
    - TeMPOraL 6y ago
      Yet somehow all these locally-computed sites end up being much more bandwidth-demanding than old-school sites. Shouldn't be like this, but that's how it ended up working in practice.
drinchev 6y ago
> You could certainly build Facebook as a fully server-rendered PHP app, but that would hurt Facebook's business because its servers would need to do more work and its users would have to wait longer for content. I think they do that mostly because for the users who’ll have to download the header 100 times for each action they’ll do. Not really sure that all benefits from SPA are hidden in company costs. Mostly they are in modern tech approach. Writing this I still agree with the article. SPA is needed when you are under authentication but publicly you can live with progressive web.
- TeMPOraL 6y ago
  > I think they do that mostly because for the users who’ll have to download the header 100 times for each action they’ll do. If only they weren't deploying some changes every other day, pretty much eliminating any benefit from caching...
cellar_door 6y ago
Also, SPA and server side rendering are not mutually exclusive. Both make sense as performance optimizations depending on the context.
mattl 6y ago
I don’t want to run your proprietary JavaScript on my computer.
pmlnr 6y ago
> It's about making desktop-class applications more accessible via the web. ... Go and take a look at a "desktop class application" from 10 years ago - say Photoshop 6. Compare the speed, the UI, the native look & feel. Go to a SPA today. Cry.
- ehutch79 6y ago
  I think a better comparison would be a networked 'enterprise' app. Think SAP or Sage or something.
- TeMPOraL 6y ago
  Yup. And if you are to compare desktop-class applications from the time where desktop apps weren't just embedded webviews with what typical web SPA does (how complex is it, how much actual content), then the first thing to remember is that this scale of desktop software had its executable size measured in dozens to hundreds of kilobytes.
4bpp 6y ago
> There's certainly some companies that are caught in the hype and build a SPA app when they would probably be better served with a simple PHP site Yeah, like your example, Facebook. Ever since their redesign, I've switched to only using the mobile+noscript site (on desktop), because the SPA version is resource-hungry to the point that it regularly DoSes whatever browser thread it gets assigned to and has UX that, ironically, seems to be terrible as anything other than a mobile app (they've replaced text with abstract square "touchable" buttons and introduced airy spacing everywhere that allows you to see maybe about half a post per screen). It's as if its designers have been trying to ram their mobile app down my throat for years (by nagging screens at first, and then by outright removing the ability to view private messages from the mobile page - except sometimes by refreshing sufficiently many times you could trigger a bug and still drop through to the old messenger view, adding insult to injury), and when I still didn't bite, they decided to replace the whole service (which up until then had been one of the last remaining decent mainstream websites) with a facsimile of one.
- kyawzazaw 6y ago
  > Yeah, like your example, Facebook. Ever since their redesign, I've switched to only using the mobile+noscript site (on desktop), because the SPA version is resource-hungry to the point that it regularly DoSes whatever browser thread it gets assigned to and has UX that, ironically, seems to be terrible as anything other than a mobile app (they've replaced text with abstract square "touchable" buttons and introduced airy spacing everywhere that allows you to see maybe about half a post per screen). I have literally not heard of anyone complaining about this (not that your argument is invalid). A whole lot of people are just not gonna bother or check how resource intensive it is.
  - pmlnr 6y ago
    > I have literally not heard of anyone complaining about this EVERYONE complains about the speed of "new" (2020?) Facebook.
  - garmaine 6y ago
    I will add my voice to the list of complainers. I stopped using Facebook after they forced me to upgrade to the new site.
kortilla 6y ago
> It's about making desktop-class applications more accessible via the web. Everyone understands this is what devs are trying to do. The complaint is that my local newspaper doesn’t need a desktop class application. Nor does my bank, nor does Reddit for that matter. There are vanishingly few websites that need a “desktop application” performance profile. Most websites are just viewing documents. The size of the SPA frameworks is frequently higher than the actual content being viewed. Finally, if matching desktop app performance is truly the goal, the majority of SPAs fail horribly. Poor request patterns and transitions make the pages just as slow as server side rendered html. I would rather wait one second to get a JS-free response than look at another damn spinning circle for 5 seconds as the page sputters new elements in.
- hmottestad 6y ago
  I use 3 different banks quite regularly and there is a huge difference between them. My latest bank has great interest rates but also the worst UI experience mostly due to every interaction causing a page reload. I’m very much hoping for more JS usage in the banking world to make the experience a bit smoother!
  - ljp_206 6y ago
    > I’m very much hoping for more JS usage in the banking world to make the experience a bit smoother! As a React developer this makes me anxious, lol.
  - Closi 6y ago
    > My latest bank has great interest rates but also the worst UI experience mostly due to every interaction causing a page reload. I think this is heavily dependent on how fast the screen refresh is. Page reloads can be quick enough to appear pretty responsive - but if the website takes 3 seconds to serve the page up that’s obviously no good.
    - hmottestad 6y ago
      Did I forget to mention that they store the application state on the server end so the back button in your browsers doesn’t work?
austincheney 6y ago
No, it’s a fad. Most corporate JavaScript developers cannot actually write JavaScript of their own. They need giant frameworks to do the heavy lifting and the output of such is a SPA. If you really wanted accessibility you wouldn’t complicate your life with screen reader compliance via a SPA. To be clear a SPA is generally a front end for user input, such as a form (or series of forms) clobbered together so that a page is loaded fewer times. This a traditional web path that exchanges page traversal for interaction, often to maintain state locally. Conversely, a browser application is an application that executes in the browser without regard for data and state, such as photoshop or a spreadsheet in the browser, which aren’t concerned with any server application.
ori_b 6y ago
> It's not popular because it's a fad, it's not about replacing good old static websites with fancy over-engineered JS code. Yet, in practice, this is what happens. When turning JS off is an option, that's usually one of the biggest improvements I can make to my page surfing experience. Things load faster, ads don't expand over content, the page reflows less often as things are injected, shit doesn't autoplay, and spinners and animations don't distract. I can just read the content. It's possible to use JS well, but I don't see it happen very often. And the unpleasantness from of abuse usually outweighs the benefits from good use.
mlang23 6y ago
> It's about making desktop-class applications more accessible via the web. If we, for a second, stick to the meaning accessibility used to have, namely, usability by people with disabilities, quite the contrary is the reality. The SPA trend, "lets just move every app into the web" fuels the digital divide like nothing else. It has become harder and harder to actually use the modern web, and a lot of why that is comes down to SPA and JS.
deleted 6y ago
[deleted]
klyrs 6y ago
> It's about making desktop-class applications more accessible via the web. The problem I see is folks unnecessarily turning their websites into desktop-class applications. It's especially popular on ecommerce sites -- today I tried to look at some lumber prices and the website had input latency measured in seconds before my phone's browser just crashed.
dsego 6y ago
The current fb/messenger interface is a disaster. Transitions are slow and they still didn't get the local state right and coordinated different parts of the UI. I've stopped using messenger because of this, managed to send messages to the wrong recipient more than once because of latency in the UI.
cosmotic 6y ago
All the popular SPAs I use have awful latency. It may have been a design goal, but huge failures all around.
kilburn 6y ago
> Some people don't seem to understand what the whole JS SPA thing is about, and it's quite strange to me. Most people understand the promises of SPAs, but there are several forces that play against everything you said: - Some websites don't need a desktop experience yet they go the SPA route. - SPAs are -in my experience- significantly harder to get right than server-rendered apps. For sites that are a good fit for "the regular old web" we are speaking about at least an order of magnitude here. - Oftentimes it is companies/products with significant resources that embark on the SPA ordeal. This usually means that they also have several teams demanding product analytics, A/B testing and what not, and hence their sites end up loaded with random shit (gtm, analytics, optimizely, facebook pixel and the kitchen-sink). For all these reasons, it takes an extraordinary (i.e: significantly better than average) team, from the developers all the way to management, to deliver on the SPA promise. As a result, most SPAs suck, and hence a lot of people cultivated an aversion to them. It really is that simple.

asddubs 6y ago

IMO you can have your cake and eat it too - just offer a fallback of some sort, it's good SEO anyway. I haven't done anything in react but it's my understanding that this is actually possible to do, have react deliver an initial pre-rendered page and then still have your fancy SPA on top of it

pkage 6y ago

HN gets frothing mad about javascript, and to some extent I agree: sites that are fundamentally about content (news websites, blogs, etc.) should not be locked behind JS gates. The amount of code bloat on those pages tends to be related to tracking and advertising, so not running JS on those pages makes sense. On the other hand, web applications that provide full-featured experiences are only possible because of the full spectrum of web technologies. Choosing not to run JS and claiming that Google Docs should work without JS is ridiculous.

resynth1943 6y ago
Aside: outline.com is useful for news websites which require JavaScript.
- dredmorbius 6y ago
  Many but by no means all. I increasingly rely on either Internet Archive's Wayback Machine (which also fails remarcably often to fully, or even partially, present SPAs), or Archive.today (archive.is, archive.fo, and friends), which is painfully slow to acquire content but does manage to render most it attempts.
mixmastamyk 6y ago
It’s almost as if you should pick the right tool for the job. ;-)
- nicbou 6y ago
  We all agree on that. I just suspect that Hacker News only knows about two jobs: massively distributed applications and their static blog. In the middle, you have countless SPAs, but also slightly interactive websites that are 90% content, and 10% calculators/maps/widgets.
  - kyawzazaw 6y ago
    feel so true
  - ehutch79 6y ago
    It's not like those widgets need a full routing system with ssr, etc. Even with vue, you can just drop that component on the page.
    - RussianCow 6y ago
      But add enough of those widgets to a page, and now you need to coordinate local state, sync it with the URL, etc, which is way easier to do when the whole page is a SPA.

aboringusername 6y ago

> It's about making desktop-class applications more accessible via the web. I am not sure what "web" you're using, but as someone who uses noscript and has been enabling scripts for over a year now, I can firmly say JS is NOT used for making "desktop-class applications more accessible". It's used for ads. And spying. Lots and lots of spying. Seriously. Googletagmanager/analytics is everywhere, it doesn't deserve to be, it doesn't need to be. That domain needs to die a painful, horrible death. facebook, twitter, sessioncam, and many others are used to bloat pages, increase my energy usage, decrease my battery quicker and contribute to the wastage of energy on an unprecedented scale. Just ask yourself, how much money, battery life, bandwidth is spent every year on downloading useless scripts that as far as I can see offer no value whatsoever. By selectively deciding what scripts to enable I get the folliowing result: 1: pages are lighter, less bloated, and STILL WORK 2: I download less scripts, use less battery and save bandwidth and energy for myself and all humanity. 3: There is less spying as fetch() requests are blocked and there can be hundreds of them across a single web-page session (you can watch really bloated pages for 10 minutes, there can be 100's of requests easily). Test: load the following two pages, study their usage, test each with JS enabled/disabled: 1: https://old.reddit.com https://old.reddit.com (with JS:2.69, without: 2.34mb) 2: https://reddit.com https://reddit.com (with JS: 8.58mb, without: 8.10kb, but the page is broken...) Baring in mind old.reddit works fine with JS disabled, showing JS is not needed for a site like reddit to work at all. Yet, "web developers" use them as if it's nothing. Pages that execute over seconds, possibly MB's of data, all the additional requests that are made to enrich the likes of FB/Google et al. So no, SPA are a scam and the web is worse today than I remember back in the 2000's, at least we didn't have cookie pop up boxes because people can't help but abuse JS. Most of the GDPR violations I've found thus far are from scripts that have no place or purpose, that slurp up user data without remorse, that, if disabled, doesn't impact the functionality of the page, and that enables the great surveillance capitalism and data-raping we are seeing today.

cellar_door 6y ago
Ok, so you want to disable tracking and ads. Why does that necessitate disabling all JS? You can enjoy the performance of an SPA while selectively disabling tracking.

h_anna_h 6y ago

> its servers would need to do more work So far I have seen no evidence that this would be the case (rather, I have reasons to believe the contrary). > and its users would have to wait longer for content. They would actually have to wait less. Recently two of the sites that I used to use switched to react. I was able to have open literally 100s of tabs with them, each of them loading almost instantly (excluding media). Now I can barely hold 2 open and they load slowly (even if we ignore the time that it takes to load the media).

wyager 6y ago

> Fully server-rendered frameworks are not capable of delivering low-latency desktop-class applications Evidently, neither is JavaScript.

shadowgovt 6y ago

To a first approximation, you can do all your heavy-cpu computation on the server and have the client be a close-to-dumb terminal or you can have the server do some preprocessing and the client do some postprocessing. One spreads the load over CPUs better.

TeMPOraL 6y ago
> One spreads the load over CPUs better. Better for companies running high-powered servers with economic benefits of scale, or for users running low-end devices? This is just dumping an externality. Also, arguably, most performance issues of SPAs don't come from business-relevant calculations being slow. It comes from scaffolding, gratuitous, and bunch of other overhead that would not happen at all, server-side.
- shadowgovt 6y ago
  The end user is also often paying for bandwidth, and doing local computation locally saves that cost.
  - TeMPOraL 6y ago
    Yet somehow all these locally-computed sites end up being much more bandwidth-demanding than old-school sites. Shouldn't be like this, but that's how it ended up working in practice.

drinchev 6y ago

> You could certainly build Facebook as a fully server-rendered PHP app, but that would hurt Facebook's business because its servers would need to do more work and its users would have to wait longer for content. I think they do that mostly because for the users who’ll have to download the header 100 times for each action they’ll do. Not really sure that all benefits from SPA are hidden in company costs. Mostly they are in modern tech approach. Writing this I still agree with the article. SPA is needed when you are under authentication but publicly you can live with progressive web.

TeMPOraL 6y ago
> I think they do that mostly because for the users who’ll have to download the header 100 times for each action they’ll do. If only they weren't deploying some changes every other day, pretty much eliminating any benefit from caching...

cellar_door 6y ago

Also, SPA and server side rendering are not mutually exclusive. Both make sense as performance optimizations depending on the context.

mattl 6y ago

I don’t want to run your proprietary JavaScript on my computer.

pmlnr 6y ago

> It's about making desktop-class applications more accessible via the web. ... Go and take a look at a "desktop class application" from 10 years ago - say Photoshop 6. Compare the speed, the UI, the native look & feel. Go to a SPA today. Cry.

ehutch79 6y ago
I think a better comparison would be a networked 'enterprise' app. Think SAP or Sage or something.
TeMPOraL 6y ago
Yup. And if you are to compare desktop-class applications from the time where desktop apps weren't just embedded webviews with what typical web SPA does (how complex is it, how much actual content), then the first thing to remember is that this scale of desktop software had its executable size measured in dozens to hundreds of kilobytes.

4bpp 6y ago

> There's certainly some companies that are caught in the hype and build a SPA app when they would probably be better served with a simple PHP site Yeah, like your example, Facebook. Ever since their redesign, I've switched to only using the mobile+noscript site (on desktop), because the SPA version is resource-hungry to the point that it regularly DoSes whatever browser thread it gets assigned to and has UX that, ironically, seems to be terrible as anything other than a mobile app (they've replaced text with abstract square "touchable" buttons and introduced airy spacing everywhere that allows you to see maybe about half a post per screen). It's as if its designers have been trying to ram their mobile app down my throat for years (by nagging screens at first, and then by outright removing the ability to view private messages from the mobile page - except sometimes by refreshing sufficiently many times you could trigger a bug and still drop through to the old messenger view, adding insult to injury), and when I still didn't bite, they decided to replace the whole service (which up until then had been one of the last remaining decent mainstream websites) with a facsimile of one.

kyawzazaw 6y ago
> Yeah, like your example, Facebook. Ever since their redesign, I've switched to only using the mobile+noscript site (on desktop), because the SPA version is resource-hungry to the point that it regularly DoSes whatever browser thread it gets assigned to and has UX that, ironically, seems to be terrible as anything other than a mobile app (they've replaced text with abstract square "touchable" buttons and introduced airy spacing everywhere that allows you to see maybe about half a post per screen). I have literally not heard of anyone complaining about this (not that your argument is invalid). A whole lot of people are just not gonna bother or check how resource intensive it is.
- pmlnr 6y ago
  > I have literally not heard of anyone complaining about this EVERYONE complains about the speed of "new" (2020?) Facebook.
- garmaine 6y ago
  I will add my voice to the list of complainers. I stopped using Facebook after they forced me to upgrade to the new site.

kortilla 6y ago

> It's about making desktop-class applications more accessible via the web. Everyone understands this is what devs are trying to do. The complaint is that my local newspaper doesn’t need a desktop class application. Nor does my bank, nor does Reddit for that matter. There are vanishingly few websites that need a “desktop application” performance profile. Most websites are just viewing documents. The size of the SPA frameworks is frequently higher than the actual content being viewed. Finally, if matching desktop app performance is truly the goal, the majority of SPAs fail horribly. Poor request patterns and transitions make the pages just as slow as server side rendered html. I would rather wait one second to get a JS-free response than look at another damn spinning circle for 5 seconds as the page sputters new elements in.

hmottestad 6y ago
I use 3 different banks quite regularly and there is a huge difference between them. My latest bank has great interest rates but also the worst UI experience mostly due to every interaction causing a page reload. I’m very much hoping for more JS usage in the banking world to make the experience a bit smoother!
- ljp_206 6y ago
  > I’m very much hoping for more JS usage in the banking world to make the experience a bit smoother! As a React developer this makes me anxious, lol.
- Closi 6y ago
  > My latest bank has great interest rates but also the worst UI experience mostly due to every interaction causing a page reload. I think this is heavily dependent on how fast the screen refresh is. Page reloads can be quick enough to appear pretty responsive - but if the website takes 3 seconds to serve the page up that’s obviously no good.
  - hmottestad 6y ago
    Did I forget to mention that they store the application state on the server end so the back button in your browsers doesn’t work?

austincheney 6y ago

No, it’s a fad. Most corporate JavaScript developers cannot actually write JavaScript of their own. They need giant frameworks to do the heavy lifting and the output of such is a SPA. If you really wanted accessibility you wouldn’t complicate your life with screen reader compliance via a SPA. To be clear a SPA is generally a front end for user input, such as a form (or series of forms) clobbered together so that a page is loaded fewer times. This a traditional web path that exchanges page traversal for interaction, often to maintain state locally. Conversely, a browser application is an application that executes in the browser without regard for data and state, such as photoshop or a spreadsheet in the browser, which aren’t concerned with any server application.

ori_b 6y ago

> It's not popular because it's a fad, it's not about replacing good old static websites with fancy over-engineered JS code. Yet, in practice, this is what happens. When turning JS off is an option, that's usually one of the biggest improvements I can make to my page surfing experience. Things load faster, ads don't expand over content, the page reflows less often as things are injected, shit doesn't autoplay, and spinners and animations don't distract. I can just read the content. It's possible to use JS well, but I don't see it happen very often. And the unpleasantness from of abuse usually outweighs the benefits from good use.

mlang23 6y ago

> It's about making desktop-class applications more accessible via the web. If we, for a second, stick to the meaning accessibility used to have, namely, usability by people with disabilities, quite the contrary is the reality. The SPA trend, "lets just move every app into the web" fuels the digital divide like nothing else. It has become harder and harder to actually use the modern web, and a lot of why that is comes down to SPA and JS.

deleted 6y ago

[deleted]

klyrs 6y ago

> It's about making desktop-class applications more accessible via the web. The problem I see is folks unnecessarily turning their websites into desktop-class applications. It's especially popular on ecommerce sites -- today I tried to look at some lumber prices and the website had input latency measured in seconds before my phone's browser just crashed.

dsego 6y ago

The current fb/messenger interface is a disaster. Transitions are slow and they still didn't get the local state right and coordinated different parts of the UI. I've stopped using messenger because of this, managed to send messages to the wrong recipient more than once because of latency in the UI.

cosmotic 6y ago

All the popular SPAs I use have awful latency. It may have been a design goal, but huge failures all around.

kilburn 6y ago

> Some people don't seem to understand what the whole JS SPA thing is about, and it's quite strange to me. Most people understand the promises of SPAs, but there are several forces that play against everything you said: - Some websites don't need a desktop experience yet they go the SPA route. - SPAs are -in my experience- significantly harder to get right than server-rendered apps. For sites that are a good fit for "the regular old web" we are speaking about at least an order of magnitude here. - Oftentimes it is companies/products with significant resources that embark on the SPA ordeal. This usually means that they also have several teams demanding product analytics, A/B testing and what not, and hence their sites end up loaded with random shit (gtm, analytics, optimizely, facebook pixel and the kitchen-sink). For all these reasons, it takes an extraordinary (i.e: significantly better than average) team, from the developers all the way to management, to deliver on the SPA promise. As a result, most SPAs suck, and hence a lot of people cultivated an aversion to them. It really is that simple.