4 ms·

Another old'ish guy here, and I feel the same way. I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is t

Another old'ish guy here, and I feel the same way. I have done a few projects using Knockout and Angular, and I've used Svelte a little too. My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX. In SSR (Server-Side Rendered) projects (typically ASP.NET Core for me nowadays, but I've used others too), things are just so much simpler, with fewer moving parts. A sprinkling of JavaScript is all that's needed, and even then a lot is reusable between projects. And now IE has finally died, jQuery is no longer needed, and browser support for ES6 is good, even writing JavaScript is less miserable than it used to be.

deleted 5y ago
[deleted]
zdragnar 5y ago
Is it not simpler because the applications themselves are simpler? I mean, when you say that client frameworks like angular and svelte have their place with complex UX/UI interactions. Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.
- _9omd 5y ago
  > your domain is simpler This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.
  - stepbeek 5y ago
    I use miro and figma as examples of products that would be extremely hard to build as a traditional SSR app.
- naasking 5y ago
  > your domain is simpler. So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.
  - zdragnar 5y ago
    OP said: > My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX. Therefore, it follows that OP finds SSR is simpler, but only because OP only uses SSR for simple problems.
    - naasking 5y ago
      Non-complex UI/UX != Simple problems. Also, most problems people have don't need complex UI/UX.
robertoandred 5y ago
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".

deleted 5y ago

[deleted]

zdragnar 5y ago

Is it not simpler because the applications themselves are simpler? I mean, when you say that client frameworks like angular and svelte have their place with complex UX/UI interactions. Of course SSR is simpler- request in, send / receive from a database, markup out. It isnt anything to do with SSR- your domain is simpler.

_9omd 5y ago
> your domain is simpler This echos my thinking whenever these framework/SSR/JavaScript debates come up. It's like everyone is talking past each other because there is no clarity around the complexity of what's being built.
- stepbeek 5y ago
  I use miro and figma as examples of products that would be extremely hard to build as a traditional SSR app.
naasking 5y ago
> your domain is simpler. So you're saying the domain is simpler while still satisfying the client's requirements? I think that's exactly the OP's point.
- zdragnar 5y ago
  OP said: > My conclusion is that SPAs definitely have their place - but that place is in the minority, mostly for web apps with complex UI/UX. Therefore, it follows that OP finds SSR is simpler, but only because OP only uses SSR for simple problems.
  - naasking 5y ago
    Non-complex UI/UX != Simple problems. Also, most problems people have don't need complex UI/UX.

robertoandred 5y ago

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".