5 ms·

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

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
      We're using Vite.js/esbuild, the bundler takes 2.5GB of RAM locally.
      - gausswho 3y ago
        I can offer suggestions on code-splitting, but bundler memory consumption gets into the weeds quickly.
        realusername 3y ago
        Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax. That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and could make those in pretty much anything.
        gausswho 3y ago
        I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.
- deleted 3y ago
  [deleted]
- pjc50 3y ago
  In practice, the SPA is so slow and the user's device is so much slower than the datacenter that the "something" you see is a useless splash screen, and the actual content takes longer to arrive than just doing it SSR. Reddit is probably the most familiar example of this, because it actually has multiple implementations (old.reddit, i.reddit etc) that let you see the difference!
  - gausswho 3y ago
    I am wary of gleaning anything on the matter from Reddit. Their engineering decisions don't fit either the convention nor the needs of most web applications. As for whether the initial paint is of value, that comes down to product and implementation. Nothing is faster than offline-first or local cache, which SSR does not have a good narraative for.
- the8472 3y ago
  "at least seeing something" leads to jira or teams where you open a thing and then its entries slowly pop in and shift as they get loaded. An illusion of a site being there that can't be used because you can neither focus on the text nor use any of the inputs as they shift beneath your eyes.
  - gausswho 3y ago
    That'd be a poor implementation. CSR can generate immediately interactive forms that don't shift. JIRA and MS are absolutely subpar irregardless of this matter.
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

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
    We're using Vite.js/esbuild, the bundler takes 2.5GB of RAM locally.
    - gausswho 3y ago
      I can offer suggestions on code-splitting, but bundler memory consumption gets into the weeds quickly.
      - realusername 3y ago
        Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax. That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and could make those in pretty much anything.
        gausswho 3y ago
        I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.
deleted 3y ago
[deleted]
pjc50 3y ago
In practice, the SPA is so slow and the user's device is so much slower than the datacenter that the "something" you see is a useless splash screen, and the actual content takes longer to arrive than just doing it SSR. Reddit is probably the most familiar example of this, because it actually has multiple implementations (old.reddit, i.reddit etc) that let you see the difference!
- gausswho 3y ago
  I am wary of gleaning anything on the matter from Reddit. Their engineering decisions don't fit either the convention nor the needs of most web applications. As for whether the initial paint is of value, that comes down to product and implementation. Nothing is faster than offline-first or local cache, which SSR does not have a good narraative for.
the8472 3y ago
"at least seeing something" leads to jira or teams where you open a thing and then its entries slowly pop in and shift as they get loaded. An illusion of a site being there that can't be used because you can neither focus on the text nor use any of the inputs as they shift beneath your eyes.
- gausswho 3y ago
  That'd be a poor implementation. CSR can generate immediately interactive forms that don't shift. JIRA and MS are absolutely subpar irregardless of this matter.

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