Not sure if I addressed the point of: Why not just use server-side rendering all the time? Initial versions of web applications did just that, because Javascript didn't have enough features or performance to render client-side. To get new information from the server, you had to send the current state of the page back to the server (via form post, before AJAX) and let the server run logic, decide what to render next, and then render it as HTML+JS before returning to the client. Submitting a form caused the whole page to go into a loading state, effectively freezing the UI, until a network round trip + server processing was finished. Client-side rendering came later to make the UI stay interactive/responsive while requests were sent to the server. This provided a much better user experience, but often the initial load times were slow as the application files downloaded and initialized. Server-rendering comes back into the picture now as an optimization for the initial page load. Server-rendering can pre-compute the initialization phase of an otherwise client-side rendered app to save app startup time.
This one complements the previous reply and covers the second part very well. So it is a case of optimization which one should do for faster loading (initial load with server side rendering) and making use of client CPU for further route changes. Right?
But, what role SEO plays here? If we need to have server side rendering for SEO purposes then it won't just remain the case of initial page load, isn't it? We will need to have server side rendering for all those pages for which we need SEO, right? If yes, then why go for client side rendering at all?
This is a good question that I unfortunately don't know the answer to. The vast majority of my work has been behind logins, so SEO is a non-issue. I actually have the opposite experience of setting up robots.txt and other things to block search engine crawlers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not sure if I addressed the point of: Why not just use server-side rendering all the time? Initial versions of web applications did just that, because Javascript didn't have enough features or performance to render client-side. To get new information from the server, you had to send the current state of the page back to the server (via form post, before AJAX) and let the server run logic, decide what to render next, and then render it as HTML+JS before returning to the client. Submitting a form caused the whole page to go into a loading state, effectively freezing the UI, until a network round trip + server processing was finished. Client-side rendering came later to make the UI stay interactive/responsive while requests were sent to the server. This provided a much better user experience, but often the initial load times were slow as the application files downloaded and initialized. Server-rendering comes back into the picture now as an optimization for the initial page load. Server-rendering can pre-compute the initialization phase of an otherwise client-side rendered app to save app startup time.
This one complements the previous reply and covers the second part very well. So it is a case of optimization which one should do for faster loading (initial load with server side rendering) and making use of client CPU for further route changes. Right?
But, what role SEO plays here? If we need to have server side rendering for SEO purposes then it won't just remain the case of initial page load, isn't it? We will need to have server side rendering for all those pages for which we need SEO, right? If yes, then why go for client side rendering at all?
This is a good question that I unfortunately don't know the answer to. The vast majority of my work has been behind logins, so SEO is a non-issue. I actually have the opposite experience of setting up robots.txt and other things to block search engine crawlers.