4 ms·

> when I ask why they do SSR What are the reasons for not doing SSR?

scrame 1y ago
want the whole point of Javascript to use client side manipulation? Is it's come back to SSR, then do we need all the JS baggage?
- twelvechairs 1y ago
  Its a division of responsibilities thing isnt it? "Proper coders" in python or whatever provide up to an API. Past that its basically the web devs domain and they live in JS land
  - byearthithatius 1y ago
    Agree, that is why I am confused by his question to me. Like SSR should be the default. Why does your server by default "hydrate" the client bundle. Why can't the client bundle request data as it needs it (then we can only request what the user needs). Skeleton UI it while you fetch. Then you have great page load time because you just return a static HTML+JS bundle that was non-conditionally built. In SSR it talks to the DB before it even constructs the bundle, that is oof right? So you are faster because you don't even gen the HTML until you talked to the DB? I give the user plain HTML instantly and talk to the DB while I give them a UI indicating its loading. SSR just moved the load time to before initial render. Stupid IMO.
byearthithatius 1y ago
Why is it the default for you? You are worrying about hydration complexity and all that when you introduce it, so it better have some benefits. My default is a small page that client then fetches any additional data it needs. If its long load time skeleton UI it. I also have not seen the SEO benefits at all. So again _why would I_ unless I needed to do stuff on the server to make the client bundle, which I don't. A lot of these YC companies doing this could literally just be using a fetch because their backend is dead simple REST.
- array_key_first 1y ago
  SSR can be a tactic to avoid complexity. Basically, let's not duplication state on the frontend and then create synchronization. Just say the backend owns it.
  - b_e_n_t_o_n 1y ago
    Yeah, but when it's used in conjunction with js frameworks it ends up being more complicated than pure SPA or SSR.

want the whole point of Javascript to use client side manipulation? Is it's come back to SSR, then do we need all the JS baggage?

twelvechairs 1y ago
Its a division of responsibilities thing isnt it? "Proper coders" in python or whatever provide up to an API. Past that its basically the web devs domain and they live in JS land
- byearthithatius 1y ago
  Agree, that is why I am confused by his question to me. Like SSR should be the default. Why does your server by default "hydrate" the client bundle. Why can't the client bundle request data as it needs it (then we can only request what the user needs). Skeleton UI it while you fetch. Then you have great page load time because you just return a static HTML+JS bundle that was non-conditionally built. In SSR it talks to the DB before it even constructs the bundle, that is oof right? So you are faster because you don't even gen the HTML until you talked to the DB? I give the user plain HTML instantly and talk to the DB while I give them a UI indicating its loading. SSR just moved the load time to before initial render. Stupid IMO.

byearthithatius 1y ago

Why is it the default for you? You are worrying about hydration complexity and all that when you introduce it, so it better have some benefits. My default is a small page that client then fetches any additional data it needs. If its long load time skeleton UI it. I also have not seen the SEO benefits at all. So again _why would I_ unless I needed to do stuff on the server to make the client bundle, which I don't. A lot of these YC companies doing this could literally just be using a fetch because their backend is dead simple REST.

array_key_first 1y ago
SSR can be a tactic to avoid complexity. Basically, let's not duplication state on the frontend and then create synchronization. Just say the backend owns it.
- b_e_n_t_o_n 1y ago
  Yeah, but when it's used in conjunction with js frameworks it ends up being more complicated than pure SPA or SSR.