3 ms·

Server-side rendering can absolutely be slow, and client-side can absolutely be fast. It's all dependent on the quality of the developer.

Maxion 3y ago
And the complexity of the application, which isn't always up to the developer.
bob1029 3y ago
Server-side has the best chance of providing an ideal experience in the worst case situation: The user's very first visit to the website on a mobile device in a crappy network environment. Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actually find the princess upon their first request. I look at every client-side argument along the axis of "well now that the universe is already here, we can get started". Server-side explains how that universe got into existence in the first place. Your fancy incremental update shadow DOM system cannot work until it is already bootstrapped via some means.
- michaelmior 3y ago
  > Information-theoretic, there is no way you can beat SSR in this scenario. I think this is generally true, but it does depend on how long it takes SSR to complete. If that's slow, you could potentially be faster by sending a bit of JS+HTML and allowing processing to continue in the background to be fetched later when it's ready instead of waiting for everything. That said, I think that's a fairly unrealistic scenario since a bad connection with high latency is probably more of an overhead.
- nfw2 3y ago
  Not always. SSR that needs to run JavaScript hydration needs to download more content (the html and js bundle) than a spa before it’s interactive. I don’t know why the community collectively decided that first-contentful-paint is a more important metric than time-to-interactive. Seeing a page quickly and waiting a noticeable amount of time for it be functional seems like the worst possible ux, especially when there is no signal to the user when the JS has loaded.
  - bob1029 3y ago
    > SSR that needs to run JavaScript hydration This is not SSR.
- slaymaker1907 3y ago
  Even that really requires some nuance. If most of your site is static with a small amount (in terms of data) dynamic content, it could easily be faster to split things up into 2 phases: load the static part and then do a single REST request to get the dynamic part for client side rendering. The first time the user ever visits your page, it will take a small hit compared to SSR, but in subsequent visits the browser can easily cache the static part so it only needs to query for cache coherence (which should be very cheap in terms of throughput) and obviously the REST query for the dynamic parts. If you do SSR, the client is much more limited in terms of caching because the page contents is not constant. In my opinion, SSR is actually more for slow CPUs than for slow networks since you can make the network usage for client side rendering very efficient as well, but client side rendering will always be worse in terms of client CPU.
cultofmetatron 3y ago
and your ops configuration. you'll see huge differences based on how you configure your database environment as your db gets larger.

Maxion 3y ago

And the complexity of the application, which isn't always up to the developer.

bob1029 3y ago

Server-side has the best chance of providing an ideal experience in the worst case situation: The user's very first visit to the website on a mobile device in a crappy network environment. Information-theoretic, there is no way you can beat SSR in this scenario. You will not win against a machine that returns a complete HTML document on the very first request if your users only receive hints regarding where to actually find the princess upon their first request. I look at every client-side argument along the axis of "well now that the universe is already here, we can get started". Server-side explains how that universe got into existence in the first place. Your fancy incremental update shadow DOM system cannot work until it is already bootstrapped via some means.

michaelmior 3y ago
> Information-theoretic, there is no way you can beat SSR in this scenario. I think this is generally true, but it does depend on how long it takes SSR to complete. If that's slow, you could potentially be faster by sending a bit of JS+HTML and allowing processing to continue in the background to be fetched later when it's ready instead of waiting for everything. That said, I think that's a fairly unrealistic scenario since a bad connection with high latency is probably more of an overhead.
nfw2 3y ago
Not always. SSR that needs to run JavaScript hydration needs to download more content (the html and js bundle) than a spa before it’s interactive. I don’t know why the community collectively decided that first-contentful-paint is a more important metric than time-to-interactive. Seeing a page quickly and waiting a noticeable amount of time for it be functional seems like the worst possible ux, especially when there is no signal to the user when the JS has loaded.
- bob1029 3y ago
  > SSR that needs to run JavaScript hydration This is not SSR.
slaymaker1907 3y ago
Even that really requires some nuance. If most of your site is static with a small amount (in terms of data) dynamic content, it could easily be faster to split things up into 2 phases: load the static part and then do a single REST request to get the dynamic part for client side rendering. The first time the user ever visits your page, it will take a small hit compared to SSR, but in subsequent visits the browser can easily cache the static part so it only needs to query for cache coherence (which should be very cheap in terms of throughput) and obviously the REST query for the dynamic parts. If you do SSR, the client is much more limited in terms of caching because the page contents is not constant. In my opinion, SSR is actually more for slow CPUs than for slow networks since you can make the network usage for client side rendering very efficient as well, but client side rendering will always be worse in terms of client CPU.

cultofmetatron 3y ago

and your ops configuration. you'll see huge differences based on how you configure your database environment as your db gets larger.