5 ms·

The SPA vs server side rendered page debate is so exhausted at this point. The tech is such that they’re nearly equivalent if you have a good team that understa

The SPA vs server side rendered page debate is so exhausted at this point. The tech is such that they’re nearly equivalent if you have a good team that understands the appropriate technology. You can have an SPA with a proper router that respects page history, loads html fragments from a server, remembers positions on reload, etc. You can also have a server side rendered page sprinkled with JavaScript and use web sockets to create dom element level transitions and interactivity The “MPA” described in the article has always been possible in a “SPA.” It’s more about the UX of your app than anything else

j45 4y ago
Exhausted but always new to someone. It's interesting to see technologies like livewire come out that take things back to basics.
ec109685 4y ago
Your second paragraph essentially is creating a little mini browser, and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages. Performance can even be worse with SPA “page” navigation if multiple round trips are needed for the data on the next page. SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages.
- slaymaker1907 4y ago
  I think you've highlighted a big problem with SPAs in that they can encourage multiple API calls per user action. IMO, you should probably have a single endpoint per thing a user might do that might combine several conceptual APIs. i.e., if you have an API to add something to a list, have that API also return the current list.
  - BFLpL0QNek 4y ago
    I see this in most single page apps. They have a waterfall of multiple API requests by the browser to display a single page. That means the front end has a bunch of logic to aggregate and piece together requests. This in itself isn’t a big deal, if you move to doing it on the backend you still have the same logic and need to make the same sub requests. Where it does become problematic is it leads to fat API endpoints sending far more data to the client than is needed. GraphQL lets you choose what fields you query but odds are there’s still data available you can ask for that shouldn’t be asked for and sent to a browser. If your requests/aggregations are done serverside it gives you a better chance of filtering out data that should never be accessible in the browser. You can also make full use of Cache-Control headers and backend caching. Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend.
    - slaymaker1907 4y ago
      Multiple queries from the frontend is still not great because the latency is much higher than doing at the server all else being equal.
    - KRAKRISMOTT 4y ago
      > Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend. Not true, individual endpoints requires more work for client side optimizations but the CRUD query mapping effort is not reduced with graphql. If anything, graphql endpoints require more effort on the backend side to build because of having to wire up the resolvers unless you are using something like Hasura.
- EGreg 4y ago
  Is this an SPA? Or is it MPA? https://intercoin.app https://intercoin.app When you refresh, the server renders some of it.
- chrismorgan 4y ago
  > and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages You can’t get every detail right, because the browser doesn’t expose some of the pieces that would be required to do so—even apart from details that vary between browsers. The most obvious example of unexposed functionality is the loading indicator, but there are more around things like slow or failing networks.
- xmonkee 4y ago
  > SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages Everyone seems to agree on this, but if this is the case than i’m very confused why this is still a debate. The vast majority of developers are making apps, not “pages”. Pages are useful for a handful of well understood applications that already use CMS systems (blogs, ecommerce, forums etc). So why are we all pushing for MPAs instead of better apps?
simonw 4y ago
How do you make sure your SPAs work well with screen readers?
- endisneigh 4y ago
  More or less the same as a regular page - use aria labels, update names and titles of elements, make sure the focus is set correctly, etc.
  - taeric 4y ago
    And try to be frugal on the tags you make. Component design is the enemy here. Just take a peak at the nav elements in many designs and see how embedded the divs go.
    - sebazzz 4y ago
      Are you referring to styled-components and the like? What is exactly the problem with that?* * except media queries, those seem hard
      - zdragnar 4y ago
        Many prebuilt component libraries design for maintenance and all possible uses over being frugal. The actual markup can get really ugly with i.e. MUI. When you put in the effort to build the components yourself, you aren't trying to be everything for everyone, so you get to skip a lot of the cruft.
        taeric 4y ago
        Exactly this. Is a large reason to not try to build the most general components, either. Build what you need, where you can. That all said, I also have to ack that the libraries are going to be hard to beat for speed of delivery. :(
        4y ago
the_gipsy 4y ago
> You can have an SPA with a proper router that respects page history, loads html fragments from a server, remembers positions on reload, etc. In theory.
- Alifatisk 4y ago
  And in practice too?
benatkin 4y ago
No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. React seems like a bubble to me, created by fancy code that seems good at first glance but doesn't make a huge difference. What's it supposed to be amazing at, simple stuff or complex stuff? If simple stuff then why are people downloading 200K for Hello, World? If for complex stuff why isn't something like VSCode, Monaco, CodeMirror written with React? Those have state galore, and React's one-way data binding is no revelation for them. In fact inside React things like the ironically named react-hook-form get around React's one-way data binding by letting the form inputs be uncontrolled* (ironically named because react hooks makes it sound like it's going with the grain of react when it's thankfully going against it). Maybe ChatGPT will pop the bubble by churning out vanilla js that beats it. :) * https://react-hook-form.com/advanced-usage/#ControlledmixedwithUncontrolledComponents https://react-hook-form.com/advanced-usage/#Controlledmixedw... React Hook Form embraces uncontrolled components but is also compatible with controlled components.
- endisneigh 4y ago
  There are smaller SPAs like preact or mithril. One could similarly argue that why should you have to use Django to show a user hello world? It really doesn’t matter. Master your tool and most of the supposed downsides can be avoided.
  - benatkin 4y ago
    I have a lot of respect for mithril, they created a tiny vdom that works really well. Though you don't always need one. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead I have played thousands of bullet chess games on Lichees and is and was very snappy and used to be based on Mithril so it's very battle tested in a literal sense. https://bestofjs.org/projects?tags=vdom https://bestofjs.org/projects?tags=vdom FWIW I disagree that something like virtual DOM can be pure overhead. It is useful to have virtual just about anything. Virtual filesystems for instance.
- nicoburns 4y ago
  It’s good when you want interactivity that’s technically straightforward but in high volume. It doesn’t work for code editors because they need very close interaction with the DOM, whereas React provides an abstraction layer that covers the common cases.
simplotek 4y ago
> (...) they’re nearly equivalent if you have a good team that (...) That's a lot of hand-waving weasel words to blame those experiencing problems for the naturally occurring problems. If it was the same thing, we would not be having discussions on their pros and cons. This is not a team-specific issue.

j45 4y ago

Exhausted but always new to someone. It's interesting to see technologies like livewire come out that take things back to basics.

ec109685 4y ago

Your second paragraph essentially is creating a little mini browser, and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages. Performance can even be worse with SPA “page” navigation if multiple round trips are needed for the data on the next page. SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages.

slaymaker1907 4y ago
I think you've highlighted a big problem with SPAs in that they can encourage multiple API calls per user action. IMO, you should probably have a single endpoint per thing a user might do that might combine several conceptual APIs. i.e., if you have an API to add something to a list, have that API also return the current list.
- BFLpL0QNek 4y ago
  I see this in most single page apps. They have a waterfall of multiple API requests by the browser to display a single page. That means the front end has a bunch of logic to aggregate and piece together requests. This in itself isn’t a big deal, if you move to doing it on the backend you still have the same logic and need to make the same sub requests. Where it does become problematic is it leads to fat API endpoints sending far more data to the client than is needed. GraphQL lets you choose what fields you query but odds are there’s still data available you can ask for that shouldn’t be asked for and sent to a browser. If your requests/aggregations are done serverside it gives you a better chance of filtering out data that should never be accessible in the browser. You can also make full use of Cache-Control headers and backend caching. Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend.
  - slaymaker1907 4y ago
    Multiple queries from the frontend is still not great because the latency is much higher than doing at the server all else being equal.
  - KRAKRISMOTT 4y ago
    > Creating individual endpoints for web apps went out of fashion as it involves more effort and people don’t like effort to do things well. I see it re-invented recently as backend-for-frontend. Not true, individual endpoints requires more work for client side optimizations but the CRUD query mapping effort is not reduced with graphql. If anything, graphql endpoints require more effort on the backend side to build because of having to wire up the resolvers unless you are using something like Hasura.
EGreg 4y ago
Is this an SPA? Or is it MPA? https://intercoin.app https://intercoin.app When you refresh, the server renders some of it.
chrismorgan 4y ago
> and you have to make sure to get every detail right or you’re back to the uncanny valley of SPA web pages You can’t get every detail right, because the browser doesn’t expose some of the pieces that would be required to do so—even apart from details that vary between browsers. The most obvious example of unexposed functionality is the loading indicator, but there are more around things like slow or failing networks.
xmonkee 4y ago
> SPA’s should be used web apps (think slack or Asana), and stick to sever rendered for web pages Everyone seems to agree on this, but if this is the case than i’m very confused why this is still a debate. The vast majority of developers are making apps, not “pages”. Pages are useful for a handful of well understood applications that already use CMS systems (blogs, ecommerce, forums etc). So why are we all pushing for MPAs instead of better apps?

simonw 4y ago

How do you make sure your SPAs work well with screen readers?

endisneigh 4y ago
More or less the same as a regular page - use aria labels, update names and titles of elements, make sure the focus is set correctly, etc.
- taeric 4y ago
  And try to be frugal on the tags you make. Component design is the enemy here. Just take a peak at the nav elements in many designs and see how embedded the divs go.
  - sebazzz 4y ago
    Are you referring to styled-components and the like? What is exactly the problem with that?* * except media queries, those seem hard
    - zdragnar 4y ago
      Many prebuilt component libraries design for maintenance and all possible uses over being frugal. The actual markup can get really ugly with i.e. MUI. When you put in the effort to build the components yourself, you aren't trying to be everything for everyone, so you get to skip a lot of the cruft.
      - taeric 4y ago
        Exactly this. Is a large reason to not try to build the most general components, either. Build what you need, where you can. That all said, I also have to ack that the libraries are going to be hard to beat for speed of delivery. :(
        4y ago

the_gipsy 4y ago

> You can have an SPA with a proper router that respects page history, loads html fragments from a server, remembers positions on reload, etc. In theory.

Alifatisk 4y ago
And in practice too?

benatkin 4y ago

No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. React seems like a bubble to me, created by fancy code that seems good at first glance but doesn't make a huge difference. What's it supposed to be amazing at, simple stuff or complex stuff? If simple stuff then why are people downloading 200K for Hello, World? If for complex stuff why isn't something like VSCode, Monaco, CodeMirror written with React? Those have state galore, and React's one-way data binding is no revelation for them. In fact inside React things like the ironically named react-hook-form get around React's one-way data binding by letting the form inputs be uncontrolled* (ironically named because react hooks makes it sound like it's going with the grain of react when it's thankfully going against it). Maybe ChatGPT will pop the bubble by churning out vanilla js that beats it. :) * https://react-hook-form.com/advanced-usage/#ControlledmixedwithUncontrolledComponents https://react-hook-form.com/advanced-usage/#Controlledmixedw... React Hook Form embraces uncontrolled components but is also compatible with controlled components.

endisneigh 4y ago
There are smaller SPAs like preact or mithril. One could similarly argue that why should you have to use Django to show a user hello world? It really doesn’t matter. Master your tool and most of the supposed downsides can be avoided.
- benatkin 4y ago
  I have a lot of respect for mithril, they created a tiny vdom that works really well. Though you don't always need one. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead I have played thousands of bullet chess games on Lichees and is and was very snappy and used to be based on Mithril so it's very battle tested in a literal sense. https://bestofjs.org/projects?tags=vdom https://bestofjs.org/projects?tags=vdom FWIW I disagree that something like virtual DOM can be pure overhead. It is useful to have virtual just about anything. Virtual filesystems for instance.
nicoburns 4y ago
It’s good when you want interactivity that’s technically straightforward but in high volume. It doesn’t work for code editors because they need very close interaction with the DOM, whereas React provides an abstraction layer that covers the common cases.

simplotek 4y ago

> (...) they’re nearly equivalent if you have a good team that (...) That's a lot of hand-waving weasel words to blame those experiencing problems for the naturally occurring problems. If it was the same thing, we would not be having discussions on their pros and cons. This is not a team-specific issue.