What Is Server-Side Rendering?
Tags: codenewbie, beginners, node, javascript
Published: 2020-07-10 02:18:04

Over the years, rendering content on a page has developed to have a lot more possibility than just rendering from a server, which used to always be the case. Nowadays there is also client-side rendering, and both client and server sides have their pros and cons. Here are some questions I will be going through in this post:

- What is server-side rendering?
- What is server-side rendering good for and why?
- How does it differ from client-side rendering?

Let's get started!

## So...what is server-side rendering?
It's one way to send data to a user's browser in order to display content. The content itself is converted to HTML in the server, rendered, and then sent to the browser. This is why with server-side rendering, you'll see that the content of the page loads a lot faster. 

For every page the user wants to go to, a new HTML file is rendered and sent to the client. These files are often static because you're sending multiple files; for every change made, the server will send a new page with new information that is based on the change made by the user. To the user, they'll see that every page is being reloaded entirely no matter what changes they make, which won't flow as well in terms of user experience. 
 
In a nutshell, server-side rendering takes converted static files, HTML and CSS, and sends it over to the browser, where it will load the content for the user to see. If the user requests a change, the server will send a new file to reflect that change.

## What are the benefits of server-side rendering?
When you render files from the server, as mentioned above, the content on the browser will load a lot faster as the client-side doesn't need to do as much work to get the contents displayed. This makes for painting the page on the initial load a breeze, and will keep potential users on your app!

Because all the file rendering is done in the server, there will be a huge boost in performance for the client, since every page that's being sent simply needs to be loaded; the client doesn't have to do any conversions or rendering. That means that for the user, they'll likely have to wait less for any initial loads to load on their screen. This is definitely something to keep in mind if your app is serving lots of users.

Search engine optimization (SEO) will also work in your favor here. Because server-side rendering means rendering the files before they're sent, the page information will already be available to the browser before a user gets to see it, so the page information will be caught a lot quicker by the search engine's algorithm. That means your page could be one of the many apps that users see first!

Overall, server-side rendering is good for speed and performance, but this is generally helpful if you have a lot of static files as opposed to files that are more dynamic, which is what client-side rendering covers. We'll cover it briefly here, but a good rule of thumb is if your app has a lot of static files or runs statically, you'll benefit from server-side rendering. 

## What about client-side rendering?
The biggest difference between server-side rendering and client-side rendering is where the page content is rendered (you can tell from their names alone!). In this case, the content is rendered on the client-side, or the browser, which has its pros and cons.

For client-side rendering, your pages might look a lot more dynamic, especially if you're using JavaScript frameworks like React, Vue, Angular, etc. That means that the majority, if not all of the content, will be in JavaScript as opposed to HTML. The browser will render the HTML fairly quickly, but that's all the user would get until the JavaScript is rendered, and only then will the content be displayed. If your user's internet is slow, that's going to be a very slow initial load!

Unlike server-side rendering, where you'll have to send multiple pages and fully reload entire pages, client-side rendering allows for single-page applications (SPA). This can make the user's experience flow a lot more smoothly, as they won't have to load a brand new page every time they did something new. All changes made by a user will be reflected on the same page, which can look quite fast if implemented correctly.

## Conclusion
Whichever one you choose, keep in mind that they work better depending on the app you're making, and there are quite a few factors to keep in mind when choosing how to render your app, especially when it comes to a user's interaction with it and the kind of data you're working with. Getting a chance to build with both will allow for some deeper internalization!