What and Why: Server Side Rendering
This is meant to be an intro into server side rendering, starting from the ground up. I recently found myself discussing this topic with someone who was just learning programming, and more specifically just learning web development and html. He had created static html files by hand and displayed static content in those html files. He also had dabbled into css and had started to see the power of the combination of those two technologies. Javascript, what it is, how to use it, and it's purpose was still foreign to this individual, and the purpose of "the server" was still an ambiguous concept.Maybe you are in a similar place as a beginner to web development. Or potentially you have become an expert in certain area's of modern web development, and need to discover the reason web development looks the way it does in 2018. Lastly, you may also find yourself trying to explain concepts that seem basic to you and you may take for granted the purpose for some of the different parts of web development. With that said, lets start at the beginning.
HTML Files
A user navigates to a url in their browser or clicks a link. The browser tab makes a "request" to a "server" and "responds" with an "HTML page", which is the website that you as the user interact with. Let's go through the quoted phrases one by one.
A request is a network message that is sent between two computers, and contains various types of information such as where the request came from, where it should go, and potentially other information. This should be straightforward. Think about sending an actual letter. The envelope has an address of the destination, it has a return address, and is filled with information of some kind.
A server is simply another computer that is designed to be sent requests. When sent a request, it can do whatever it wants to do. It could ignore it or it could reply to the request in various different ways. What the server does needs to be agreed upon by the server, and anyone sending requests to the server. If the server did not do anything, or did random things, it would not be very useful. If however the server promises to do certain things with certain requests, then we can do something useful. For example, if you go to google.com it will give you a semi blank page with a search box. If you go to google.com/intl/en/about/, it will give you a web page filled with text and images that explain what Google is. If Google's server ignored the request, or did random and unexpected things, then there would be no use in sending requests to those urls. The same holds through for "development servers" that you use to learn web development. Often they will have a "static" or "public" folder, and if you go to the url with a path that matches the files and folders, the development server will give you the corresponding HTML page. If it did anything else, there would be no reason to use it.
In our context a response is simply the network message sent from the server back to the browser that sent the request, and it contains the HTML file corresponding to the location that the request was sent to. This is a very specific example, because browsers and servers could send all sorts of requests and responses that contain more than just HTML files. However this is the example that is most fundamental to web development, and most important for understanding server side rendering.
Lastly, and "HTML" page is simply a text file, usually with a ".html" extension, that contains text formatted in a special way, and we call this "HTML". It's formatted in just the right way so that the browser can convert this text into an interactive web page. Obviously the browser and the person writing the HTML has to agree on the format of HTML, and this is why there exists standards and documentation that every has to agree to in order for web development to work.
So far we have covered the basics of creating static HTML files, and how browsers and servers send requests and response to allow users to view these web pages. Pretty simple so far, why do anything else? Let me describe a problem that could arise with this format, and that will give us motivation to look for a solution.
The Problem
Imagine you have a website that has multiple pages. Each page of the website is represented by a custom URL such as the following:
- www.mywebsite.com/home.html
- www.mywebsite.com/about.html
- www.mywebsite.com/products.html
- www.mywebsite.com/location.html
Each page contains different text and images, but the top of the website of each page is the same. At the top of each page there is a "navigation" section that contains links to the other pages, so that the user can easily navigate between pages. With static html pages, you would need to copy this portion of the HTML into each HTML file. If you wanted to change anything about this section of the page you would need to make this page in each file. Now imagine you have a thousand pages instead of four, and that there are dozens of sections of HTML that are shared and reused throughout all of these pages. This is a lot of effort to upkeep and a lot to remember. In fact, this can become so complex that it becomes nearly guaranteed to break. That is, the HTML of the different sections that is supposed to be the same on every page, becomes different in different places. This is what we call a maintenance nightmare.
The Solution
Now imagine that instead of creating full HTML files we create files that contain "snippets" of HTML. So instead of starting with "<html>" and ending with "</html>", it just contains smaller pieces of HTML. To go back to our previous example, you could have a file called "navigation.html". Then, when the "www.mywebsite.com/about" request comes to the server, instead of simply responding with "about.html", the server does a little bit of extra work. It could take "about.html", and then put into the top of this file "navigation.html". That way, if the navigation needs to change, you can change it in a single place, and every web page will be updated. This is called server side rendering.
Templating Languages
In reality this is not how server side rendering is done. Instead what happens is that the web developer will write in a language that looks a lot like HTML, but contains place holders that the server will fill with other pieces of HTML when the request from the user comes to the server. For example you could have an HTML file that contains placeholders for a header section, the navigation, a footer section, and so on. Then, when the server receives a request from the user, it fills those placeholders with the contents of the other HTML files.
I hope this has been a good intro into server side rendering. It was meant to take someone who is brand new to web development understand the reason why, and so was targeted to that audience, which explains why we had to start from the ground up. Thank you for reading and come back soon for more on web development!
