4 ms·

"This was called client-side rendering (CSR) or single-page applications (SPA) and was widely considered a bad move." Why was it considered a bad move to go SP

"This was called client-side rendering (CSR) or single-page applications (SPA) and was widely considered a bad move." Why was it considered a bad move to go SPA? I generally disagree with this statement. But I feel like whenever this conversation comes up we're talking different applications altogether. A SPA is fine for a back office application. What it's not necessarily good for is a splash page or marketing page where each page truly operates independently. But in the case of an app that people use frequently, the client side code all gets cached locally anyways, and SSR doesn't buy you anything for that use case. SSR is great for getting a fast time to render on the very first hit to a page. But if you're making a real, rich app, that people will use daily client side JS is not bad at all. I worked on Trello for a while, it was a single page app with a Node.js API. We served millions of users with it, and people generally loved the UX of our app. But it was a true web app, and not a website. Interactivity was always part of the user experience, and many of the behaviors would be impossible in a pure SSR app.

onion2k 3y ago
Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wait for things. The page just doesn't render until it has the data it needs. - You don't send the user code they don't need yet. If someone is viewing a page that doesn't have a widget, but you send them the code for the widget because you've bundled everything the site needs into one JS file, you've wasted the users time and bandwidth. SSR is a very easy way to solve that problem. I'm of the opinion that SSR is a better alternative to a bad SPA, but marginally worse than a good SPA, so for most teams it's a good approach because building a good SPA is hard. If people want to use SSR and that results in me not seeing 4MB homepages any more that can only be considered a win.
- gausswho 3y ago
  The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.
  - colordrops 3y ago
    Or just don't even bundle if you can serve your users with ES6 modules.
    - TheAceOfHearts 3y ago
      Performance with native ESM isn't great since you get cascading requests, unless you have very shallow dependency trees.
      - colordrops 3y ago
        They work fine for everything that doesn't require immediate response on first load, and even the there are ways to address that - for instance special pages for entry points and/or loading indicators. For general performance you can cache the modules using a service worker. In any case they are fine for most use cases.
  - realusername 3y ago
    That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.
    - gausswho 3y ago
      Perhaps I can help? Which bundler? What issues are you encountering?
      - realusername 3y ago
- Osiris 3y ago
  Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?
  - 4hg4ufxhy 3y ago
    You still need to do it, but now you additionally have a serialized data format in between client and server. Now you need to keep that format versioned and backwards compatible, otherwise users with cached clients will break.
    - Scarblac 3y ago
      We need to do that anyway, our customers call our application through our API. Building our web apps on top of the same ensures that they have the full functionality available, kind of eating our own dog food. (but yes, we have unusual customers I guess)
  - zarzavat 3y ago
    Indeed, the longer you are around you see these cycles repeat again and again. Thin client vs thick client has been a point of contention since mainframes and minicomputers.
  - simonbarker87 3y ago
    Where do you propose database lookups get done in the JS+API world? Surely they are getting done on the server that hosts the API? Unless you are using something like Firebase or SupaBase which can sort of enable client side database access (but not really, it’s still doing it on a server, just their server and running the call through RLS or similar)
  - papichulo2023 3y ago
    When I read that I felt grateful to not work wherever this person works
  - pjc50 3y ago
    You've still got to do DB lookups to serve the API, except now your DB traffic has to go through more and longer pipes?
- Scarblac 3y ago
  > - You don't send the user code they don't need yet. If someone is viewing a page that doesn't have a widget, but you send them the code for the widget because you've bundled everything the site needs into one JS file, you've wasted the users time and bandwidth. SSR is a very easy way to solve that problem. Just saying: the generated HTML could be a lot larger than the Javascript generating it. Usually it won't be, but it's not a given that sending the HTML is less bandwidth.
- tcfhgj 3y ago
  > It also reduces the complexity of the page - devs don't need to build logic to wait for things. The page just doesn't render until it has the data it needs. Devs don't need that anyways, since frameworks like Angular provide this ootb, may it be dynamic template renders (ngif) or as a prereq for finishing routinh
Cannabat 3y ago
Most judgements I've read online of CSR vs SSR miss that distinction of website and web-based application. Clearly if your website essentially just retrieves some data and displays it to the user, you can use SSR. It seems most frontend discussion - and even most of the frontend dev velocity - focuses on this context. Other common advice is "you don't need global state mgmt - use component state and a query library with good caching". Nigh impossible to retain performance and high interactivity without redux/mobx/etc. It's very empowering to be able to create sophisticated web apps that run on any device with a web browser! SPA is a very valuable pattern.
iaaan 3y ago
I agree. I feel like in my decade or so of professional experience, server-side rendering has made sense a handful of times and client-side rendering has made sense a handful of times. As you're saying: each tool comes with its own strengths and weaknesses and you should really just aim to understand the use case for each so you know when to apply them, rather than look for some one-sentence dogma about which thing is the devil to recite back to yourself when presented with a choice.
mook 3y ago
As you say it's very context dependent. Trello makes sense as an SPA because the user stares at the same page all day (the board view), for long stretches at a time, and often requires interaction like dragging cards around. For Google Maps the user spends some time finding the right location, and does a lot of panning. The HR solution my company uses… there the user goes to very distinct pages (time off, goal setting, etc.) and interacts with it by filling in forms. That probably shouldn't be an SPA (but is). It's considered a bad move to use SPAs because product managers tend to err on writing an app when they should be writing a site; the reverse rarely happens these days.
deleted 3y ago
[deleted]
jamil7 3y ago
That statement also stood out to me. I suppose the issue was that JS developers cargo cult and started creating everything as a SPA and bootcamps pumped out React developers who only knew how to make SPAs. This generation is now discovering server rendered html through React.
skippyboxedhero 3y ago
SPA required building out a separate back-end API, it had poor load times because everything had to be loaded at once (then you had all the complexity to find solutions within that paradigm with code-splitting), there was always this gap with the HTML part of the site, you had all the complexity with bundling, lots of reasons. Trello is probably an example of an app that worked with SPA. But the other perspective of this is that people weren't sensible about using React, they tried to use it for everything, they got onto React because they could hire for a very discrete front-end role and then split back-end, very few companies did this sensibly. The big problem with React was really how people used it, and this seems to have guided the development efforts on the project. Btw, the move to SSR is already having operational issues. I have noticed companies hiring now for "full-stack React" because they hired a lot of front-end specialists who don't know anything about Node and won't learn it...so I think the issues with hiring will continue.
dardarbinks 3y ago
Author, here! That line was a fun, sassy one. And probably a bit too strong. I definitely meant to temper it with the next few sentences. > Sure, it’s simple, which is worth a lot! … And for frequently changing, highly interactive pages like a dashboard, it’s probably enough I spent years working on a medical dashboard SPA and we never once seriously talked about SSR. They totally have a time and a place for web apps. I agree with you and I’m glad you brought it up.

onion2k 3y ago

Why was it considered a bad move to go SPA? There are two main advantages of SSR; - API calls necessary to build the page happen in the data center instead of the public internet, so they're much faster. You can use a database query instead of an HTTP API call if you really want to. That results in a huge speed gain for a lot of sites. It also reduces the complexity of the page - devs don't need to build logic to wait for things. The page just doesn't render until it has the data it needs. - You don't send the user code they don't need yet. If someone is viewing a page that doesn't have a widget, but you send them the code for the widget because you've bundled everything the site needs into one JS file, you've wasted the users time and bandwidth. SSR is a very easy way to solve that problem. I'm of the opinion that SSR is a better alternative to a bad SPA, but marginally worse than a good SPA, so for most teams it's a good approach because building a good SPA is hard. If people want to use SSR and that results in me not seeing 4MB homepages any more that can only be considered a win.

gausswho 3y ago
The first argument leads to waiting to see anything vs at least seeing something. Many use cases the latter is preferable. The second case is a common misconception of modern SPA. Code-splitting has been around for a while now. When split across routes it's trivial to implement.
- colordrops 3y ago
  Or just don't even bundle if you can serve your users with ES6 modules.
  - TheAceOfHearts 3y ago
    Performance with native ESM isn't great since you get cascading requests, unless you have very shallow dependency trees.
    - colordrops 3y ago
      They work fine for everything that doesn't require immediate response on first load, and even the there are ways to address that - for instance special pages for entry points and/or loading indicators. For general performance you can cache the modules using a service worker. In any case they are fine for most use cases.
- realusername 3y ago
  That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.
  - gausswho 3y ago
    Perhaps I can help? Which bundler? What issues are you encountering?
    - realusername 3y ago
Osiris 3y ago
Doing database lookups on the server was the primary reason people STOPPED doing server side render and shifted to JS+API. Why do we now think that the way we used to do it was actually better?
- 4hg4ufxhy 3y ago
  You still need to do it, but now you additionally have a serialized data format in between client and server. Now you need to keep that format versioned and backwards compatible, otherwise users with cached clients will break.
  - Scarblac 3y ago
    We need to do that anyway, our customers call our application through our API. Building our web apps on top of the same ensures that they have the full functionality available, kind of eating our own dog food. (but yes, we have unusual customers I guess)
- zarzavat 3y ago
  Indeed, the longer you are around you see these cycles repeat again and again. Thin client vs thick client has been a point of contention since mainframes and minicomputers.
- simonbarker87 3y ago
  Where do you propose database lookups get done in the JS+API world? Surely they are getting done on the server that hosts the API? Unless you are using something like Firebase or SupaBase which can sort of enable client side database access (but not really, it’s still doing it on a server, just their server and running the call through RLS or similar)
- papichulo2023 3y ago
  When I read that I felt grateful to not work wherever this person works
- pjc50 3y ago
  You've still got to do DB lookups to serve the API, except now your DB traffic has to go through more and longer pipes?
Scarblac 3y ago
> - You don't send the user code they don't need yet. If someone is viewing a page that doesn't have a widget, but you send them the code for the widget because you've bundled everything the site needs into one JS file, you've wasted the users time and bandwidth. SSR is a very easy way to solve that problem. Just saying: the generated HTML could be a lot larger than the Javascript generating it. Usually it won't be, but it's not a given that sending the HTML is less bandwidth.
tcfhgj 3y ago
> It also reduces the complexity of the page - devs don't need to build logic to wait for things. The page just doesn't render until it has the data it needs. Devs don't need that anyways, since frameworks like Angular provide this ootb, may it be dynamic template renders (ngif) or as a prereq for finishing routinh

Cannabat 3y ago

Most judgements I've read online of CSR vs SSR miss that distinction of website and web-based application. Clearly if your website essentially just retrieves some data and displays it to the user, you can use SSR. It seems most frontend discussion - and even most of the frontend dev velocity - focuses on this context. Other common advice is "you don't need global state mgmt - use component state and a query library with good caching". Nigh impossible to retain performance and high interactivity without redux/mobx/etc. It's very empowering to be able to create sophisticated web apps that run on any device with a web browser! SPA is a very valuable pattern.

iaaan 3y ago

I agree. I feel like in my decade or so of professional experience, server-side rendering has made sense a handful of times and client-side rendering has made sense a handful of times. As you're saying: each tool comes with its own strengths and weaknesses and you should really just aim to understand the use case for each so you know when to apply them, rather than look for some one-sentence dogma about which thing is the devil to recite back to yourself when presented with a choice.

mook 3y ago

As you say it's very context dependent. Trello makes sense as an SPA because the user stares at the same page all day (the board view), for long stretches at a time, and often requires interaction like dragging cards around. For Google Maps the user spends some time finding the right location, and does a lot of panning. The HR solution my company uses… there the user goes to very distinct pages (time off, goal setting, etc.) and interacts with it by filling in forms. That probably shouldn't be an SPA (but is). It's considered a bad move to use SPAs because product managers tend to err on writing an app when they should be writing a site; the reverse rarely happens these days.

deleted 3y ago

[deleted]

jamil7 3y ago

That statement also stood out to me. I suppose the issue was that JS developers cargo cult and started creating everything as a SPA and bootcamps pumped out React developers who only knew how to make SPAs. This generation is now discovering server rendered html through React.

skippyboxedhero 3y ago

SPA required building out a separate back-end API, it had poor load times because everything had to be loaded at once (then you had all the complexity to find solutions within that paradigm with code-splitting), there was always this gap with the HTML part of the site, you had all the complexity with bundling, lots of reasons. Trello is probably an example of an app that worked with SPA. But the other perspective of this is that people weren't sensible about using React, they tried to use it for everything, they got onto React because they could hire for a very discrete front-end role and then split back-end, very few companies did this sensibly. The big problem with React was really how people used it, and this seems to have guided the development efforts on the project. Btw, the move to SSR is already having operational issues. I have noticed companies hiring now for "full-stack React" because they hired a lot of front-end specialists who don't know anything about Node and won't learn it...so I think the issues with hiring will continue.

dardarbinks 3y ago

Author, here! That line was a fun, sassy one. And probably a bit too strong. I definitely meant to temper it with the next few sentences. > Sure, it’s simple, which is worth a lot! … And for frequently changing, highly interactive pages like a dashboard, it’s probably enough I spent years working on a medical dashboard SPA and we never once seriously talked about SSR. They totally have a time and a place for web apps. I agree with you and I’m glad you brought it up.