What is the difference between static and dynamic websites? What are the advantages of one over another? Which ones can I use with GitLab Pages? What about Static Site Generators?
If these questions ring a bell, this series of posts is for you! We are preparing three articles around the same theme "Static Site Generators (SSGs)".
This is Part 1: Dynamic vs Static Websites, where we go over their differences, pros and cons.
Stay tuned for the next two posts:
Note: For this series, we assume you are familiar with web development, curious about Static Site Generators, and excited to see your site getting deployed with GitLab Pages.
Dynamic websites are more complicated than that. Besides the markup, the styles and the behavior, they do more things that our web browsers can identify. For example, if you are buying something online, it's easy to understand that the prices and the availability of that item are dynamically recovered from some data, generally stored in databases. This process of recovering data and processing it before responding to our browsers as web pages containing that information, is called server-side processing.
Now let's take a better look into these processes to be able to understand how those things work, how important they are, and why this information is useful for us. How about starting from the beginning?
About 25 years ago, in 1990, Tim Berners-Lee published the first website in history. It was a plain static webpage with a few tags and links. Three years later, in 1993, the birth of the dynamic web took place, when the Common Gateway Interface (CGI) was first introduced. CGI was a way to let a website run scripts on the web server and display the output. From then on, the evolution was huge.
With the advent of processing server-side scripts, came forward the Web Content Management Systems (WCMS), allowing us to create and maintain databases connected to the internet. Websites with such server-side processing, which provide high-level interactivity with the user, are commonly referred as web applications. GitLab is one of them. Some notable examples are WordPress, Joomla!, Drupal, Magento, Ghost, and many others.
Besides connecting websites with databases, the dynamic web is an important asset to work with template systems. By using them, developers write fast, update websites faster, and reduce mistakes (provoked by repetition).
Unfortunately, with the growing popularity of server-side based websites, came together their vulnerabilities. Security issues are common among them, and there are a lot of measures we need to take to prevent attacks of uncountable natures. We need to protect our users, our site, and our server. Everything in between is subjected to attacks.
An intelligent counter-measure for avoiding those security threats and, at the same time, maintaining the benefits of templating systems, was the creation of Static Site Generators (SSGs). With them, we write dynamically and publish statically.
SSGs came out on the early 2000's, with Blosxom in 2003, and WebGen in 2004. In 2008, Tom Preston-Werner released Jekyll, by far the most popular SSG up to now. The interest for Static Site Generators have increased considerably in the last few years, as you can see at the chart below, from Google Trends:
Let's take a look at the image below and see how static pages and dynamic pages communicate with the web server.
Every browser (known as client) communicates with web servers only, via HTTP (HyperText Transfer Protocol), with a URL (Uniform Resource Locator).
Scheme A: the client (web browser) sends an HTTP request to the web server with a URL. The HTML (HyperText Markup Language) file requested, stored in the web server, is immediately returned to the client with an HTTP response, and its content is interpreted by the browser and then displayed to the user. This is known as client-side processing.
Scheme B: the client sends an HTTP request to the web server, which dispatches the request to the application server. The application server may request data from a database first, and then constructs the HTTP response based on the data recovered from the database. This response is passed back to the web server, which returns the HTML file, constructed by the application server, to the client, via HTTP response. This is called server-side processing.
The main difference is, dynamic webpages are not served as-is by the web server as static pages are. They are constructed for every HTTP request sent by each client.
These additional steps, necessary for dynamic websites, increase the time for the user to receive the HTTP response from the server with the requested page (URL). And nobody likes waiting.
Server resources are also affected by dynamic websites as for each HTTP request, the same content needs to be constructed again and again.
There's another main advantage of static over dynamic sites. Static pages don't process user data, circumventing a major security issue related to dynamic web applications: user privacy. If the users don't send any data to your server, there is no data to be stolen.
Fully-featured server providers (Scheme B) have the capability of processing server-side scripts for web applications. Their structure is more complex and naturally more expensive, whereas static web servers (Scheme A), which only handle static pages, can be maintained with less cost. With GitLab Pages you can host your site for free.
The majority of web developers don't write static sites anymore. It does take a lot more time, both to write and update, than dynamic ones. But, as previously commented, SSGs resolve this problem. We can code dynamically and the SSG outputs only static webpages for us. That's the content uploaded to our web server, in this particular case, GitLab Pages, which runs on NGINX.
Stay tuned for the next article of this series, in which we will provide you with an overview on Modern Static Site Generators, explaining how they work, what they support, and why should we really consider using SSGs for our sites.
See you there!
Don't you have an account on GitLab.com yet? Let's create one!
Follow @GitLab on Twitter and stay tuned for updates!