GitLab on SSGs: Static and Dynamic Meet in the Middle

DZone 's Guide to

GitLab on SSGs: Static and Dynamic Meet in the Middle

In this post, I sum up a good bit of the coverage GitLab has provided on SSGs and how to incorporate them in GitLab Pages.

· Web Dev Zone ·
Free Resource

Recently, there have been some truly excellent posts on GitLab about the differences between static and dynamic websites, the ins and outs of static site generators (SSGs), and using GitLab Pages in conjunction with SSGs. In this post, I plan on summing up this series, offering up some of the major insights that GitLab has provided.

Let's get to it!

Static vs. Dynamic Websites

Static websites behave just like the name suggests... they do not change. They are written in a file one time, and the contents inside them stay the same unless the file is opened up and modified directly.

These websites are built out of a conglomeration of HTML markup, CSS, and JavaScript. They're stored as simple files on a server and accessed by a remote client through a web browser. The flow can be described as follows:

  • The user tells the web browser what he/she wants.
  • The browser sends an HTTP request to the web server.
  • The server makes sense of that request and returns data back to the browser (and thus, the user) by way of an HTTP response.

Image title

Image from GitLab's post: SSGs Part 1: Static vs Dynamic Websites

Despite also being built out of HTML markup, CSS, and JavaScript, dynamic websites work quite a bit differently. Again, like the name suggests, these websites can change depending upon the external sources that they pull data from. Their files are more complicated and reference databases for specific information. If information in a database is changed, then that corresponding information on a dynamic site also changes accordingly. The flow can be described as follows:

  • The user tells the web browser what he/she wants.
  • The browser sends an HTTP request to the web server.
  • The server can't make sense of that request on its own, but is told to pass the request on to an application server.
  • The application server pulls the requested information from a database, returning data back to the web server, and eventually back to the browser (and thus, the user) by way of an HTTP response.

Image title

Image from GitLab's post: SSGs Part 1: Static vs Dynamic Websites

One of my favorite parts of GitLab's coverage of static and dynamic sites revealed a little about the history of the web. They linked to the first website ever created—born in the year 1990, this static site doesn't have a lot going on compared to today's websites. And, also as noted in the article, three years later came the first dynamic site thanks to the introduction of the Common Gateway Interface.

The Pros and Cons

Let's discuss the different advantages and disadvantages that each type of webpage offers down below...

Static Websites

Pros Cons
fast load times

more prone to coding mistakes—changes can't be made in a templated way

safer for users—no information is sent from the client, only retrieved less interaction is allowed because information is not sent from client—only hyperlinks are interactive
simple to develop (for small sites with uncomplicated designs)

hard to manage design/content changes with larger sites

doesn't automatically pull updates from database

Dynamic Websites

Pros Cons
coding mistakes are less frequent because repetition of coding is decreased 

more expensive on performance

allows for more user interaction with a website  riskier for users—data is often sent from a user to the server 

allows for devs to make sweeping changes (design and content) across a website

requires more coding in the beginning

expensive web hosting

To sum it up, if you're looking to create a small, simple, one-off webpage that doesn't require much interaction from a user—just reading—then a static site will probably suffice. However, if you're hoping to create an interactive website that is likely to need changes later on, you'd most likely want a dynamic site.

Or, if you want a mix of the two, then maybe a static site generator (SSG) is what you're after...

Static Site Generators (SSGs)

SSGs are software designed to allow web developers the ability to dynamically code across multiple sites in one swooping maneuver while outputting these changes to generate individual static sites.

These sites offer most of the perks of dynamic websites (ability to code quickly and provide mostly interactive websites) while avoiding their various downfalls (performance-heavy, server-side processing and expensive web hosting).

It's a combination of these features that allows SSGs to operate:

  • Engine/Platform – made up of the programming language the engine is created on; allows for the SSG to have different traits
  • Template Engine – allows for dynamic qualities like sweeping changes across multiple static sites
  • Markup – a system for writing docs and distinguishing code from text
  • Preprocessors – speed up the coding process
  • Directory – different file structuring for different SSGs

If you want a more thorough overview of these, I suggest looking here.

While it's clear that SSGs have plenty of pros, I haven't yet talked about their cons...

  • They don't provide the ability to register users or offer admin features.
  • They don't provide the ability to send email by using the mail() function.
  • They don't allow use of any server-side language or script.   

Luckily, there are workarounds for these.

SSGs and GitLab Pages

So, what's the connection between SSGs and GitLab?

Image title

With GitLab Pages, you can host and build any SSG out there for free. And, they provide you with plenty of documentation in case you run into any troubles in the process. As GitLab states, you're able to "use custom domains, SSL/TLS certificates, create as many sites as you want, and deploy your site from private repositories."

Want to see some examples of SSGs hosted on GitLab? Check out this handy table of SSG sites built with GitLab Pages with each entry organized by the environment it was created in.

Wrapping Up

It's not so much the fact that GitLab is hosting SSGs with GitLab Pages for free that won me over... though that is quite cool. Rather, I'm just very happy with the way that they've opened up to their community in this series.

I really like the overall flow here—telling the history behind static and dynamic sites (and the Web, in general), going over the basics of SSGs, and reeling it back in to how this all relates to GitLab. I have to give credit to Marcia Ramos for writing such a thorough and enjoyable (thoroughly enjoyable) series.

Also, I was especially happy to read this comment from a GitLab employee to a reader who felt the series was too elementary...

Image title

I really enjoyed this sentiment because this shows the inclusive environment GitLab is trying to foster—one that we too strive to promote here at DZone. While they're obviously directed toward developers, GitLab is also open to those just beginning or even those outside the typical spectrum of devs and programmers. And, I think this is always the best approach. After all, everybody has to start somewhere.  

Keep an eye on the GitLab blog for more great posts like these! And, consider making use of GitLab Pages while you're at it.

dynamic, gitlab, ssg, static, static site generator, web dev

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}