You failed to mention one big advantage of server side rendering which is security. Clients cannot see and potentially manipulate data being sent to the backend. There are of course ways to prevent data manipulation, but this is something you don't even have to think about when all logic is handled on the server and processed before sending the output to the client.
And a major disadvantage of server side rendering that you didn't mention is that you require a full page reload to change any content on the page. If you need to scroll to page 2 of a record set, the entire page must be reloaded. Client side rendering is much faster at this as it can do a simple API call and just load the new data into the table without needing to reload all of the page assets. This makes your biggest advantage of "server side being faster" very conditional on the type of content and interactions the user has with the content.
Overall good article, but I think you needed to mention those points.
This isn't quite true. With SSR apps you still have to support some form of a user modifying data (adding a like to a post or sending a comment) via POST or equivalent requests
It's in this act of giving the ability to the users that security is brought into question because then you have to start thinking about verifying the inputs and authentication and all that. SSR apps can't avoid ANY of this, they have to think about it as much as client rendered apps.
On the other hand, client rendered apps without any authentication or ability for users to modify anything gain the same benefit of "not having to think about security" anyway. So this benefit isn't tied to a rendering method, but to the content being rendered and potentially modified
Client-side or SSR, security-sensitive items need to be handled on the backend; however, there needs to be input validation on both frontend (for good UX) and backend (for data integrity/security).
Also, SSR doesn't necessarily mean that renders are only handled by page load. It's very common for SSR to perform initial render and then hand off to the client for hydrating without additional page loads.
It’s crazy how easily some people seem to get offended (or assume someone else would be offended) these days. If you are not ready to take constructive criticism online then better not to write anything at all.
You fail to mention where I said overall it was a great article, I just feel it could have included certain other points relevant to the topic. Sorry if I offended anyone, and sorry if my comment was not 100% accurate.
At the end of the day, server side rendering or client side, you cannot make a speed comparison without context of the use case. What if you are submitting some data to be processed, on server side your page would be "hung" until the server processed it and was able to generate content for the page reload after having done its logic. Client side could give you a progress bar and simply wait for an API call to complete and refresh on the page just the relevant components. There are too many variables to just say "server side is faster", that is all I was trying to mention in my comment.
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.
You failed to mention one big advantage of server side rendering which is security. Clients cannot see and potentially manipulate data being sent to the backend. There are of course ways to prevent data manipulation, but this is something you don't even have to think about when all logic is handled on the server and processed before sending the output to the client.
And a major disadvantage of server side rendering that you didn't mention is that you require a full page reload to change any content on the page. If you need to scroll to page 2 of a record set, the entire page must be reloaded. Client side rendering is much faster at this as it can do a simple API call and just load the new data into the table without needing to reload all of the page assets. This makes your biggest advantage of "server side being faster" very conditional on the type of content and interactions the user has with the content.
Overall good article, but I think you needed to mention those points.
This isn't quite true. With SSR apps you still have to support some form of a user modifying data (adding a like to a post or sending a comment) via POST or equivalent requests
It's in this act of giving the ability to the users that security is brought into question because then you have to start thinking about verifying the inputs and authentication and all that. SSR apps can't avoid ANY of this, they have to think about it as much as client rendered apps.
On the other hand, client rendered apps without any authentication or ability for users to modify anything gain the same benefit of "not having to think about security" anyway. So this benefit isn't tied to a rendering method, but to the content being rendered and potentially modified
Client-side or SSR, security-sensitive items need to be handled on the backend; however, there needs to be input validation on both frontend (for good UX) and backend (for data integrity/security).
Also, SSR doesn't necessarily mean that renders are only handled by page load. It's very common for SSR to perform initial render and then hand off to the client for hydrating without additional page loads.
Imagine taking the time to write an article to educate people and being told by someone, "you failed to mention".
Please be more considerate when writing comments. This could have been worded a lot better.
It’s crazy how easily some people seem to get offended (or assume someone else would be offended) these days. If you are not ready to take constructive criticism online then better not to write anything at all.
You fail to mention where I said overall it was a great article, I just feel it could have included certain other points relevant to the topic. Sorry if I offended anyone, and sorry if my comment was not 100% accurate.
At the end of the day, server side rendering or client side, you cannot make a speed comparison without context of the use case. What if you are submitting some data to be processed, on server side your page would be "hung" until the server processed it and was able to generate content for the page reload after having done its logic. Client side could give you a progress bar and simply wait for an API call to complete and refresh on the page just the relevant components. There are too many variables to just say "server side is faster", that is all I was trying to mention in my comment.