I’ve already made a personal site with GitHub Pages, but I’m still curious about all the other options. I’m really tempted to see how quickly I could replicate the original site with alternative solutions. Of course, if I’m really sincere in my desire to learn, I’d be well served to write about my experience.
At the moment, I’m most interested in static site generators, but I’d also like to try more conventional, “always on” solutions.
So, the question is, how does one best deliver one’s thoughts to another human through a web browser?
If the answer is “make a website”, it’s time to break it down into smaller pieces, because there are probably as many ways to make a website as are ways to open a restaurant.
A hypothetical restauranteur faces numerous choices:
- the choice of menu items,
- the decor,
- the kitchen equipment,
- the behaviour of the wait staff,
- the building location,
- the customer parking,
- locks and alarms,
- and so on.
Similarly, a recipe for a website comprises:
- the selection of content,
- the visual design,
- the user experience design,
- the document handling tools,
- the server’s programming languages (if any),
- the HTTP server,
- caching technologies,
- the domain name and URL schemes,
- security necessities such as SSL,
- and so on.
The number of combinations of possibilities is understandably daunting.
Overview of Website Architecture
The best way to grasp an overview of possible solutions would be to trace the path of information flowing between author and reader, and enumerate the variables potentially affecting that path. Let’s trace upstream from reader to author, because there’s little variability in the final legs of a web page’s trip, and much variability in the middle and earlier.
The first web browser had originally been a simple viewing and navigating layer between human client and machine server. Early web servers did little more than to obediently deliver a file from disk over the network, upon request. With this simple system, there were few choices:
- Which document editor will you use to write the raw content of your pages?
- Will the document contain embedded functionality for the browser to bring to life?
- If extra, dynamic functionality is being created, what tools will do it?
- To which web browser applications and versions will you cater?
- How is the web formatted file produced before it’s given to the web server machine?
- How will you copy the file to the web server machine?
- What web server software and operating system are on the server machine?
- What web addresses will the site’s pages use?
Beginning with this simple foundation, we get all possible combinations of what would these days be called “static websites”.
For static websites, all content is fully formed in advance, and the software or person responsible doesn’t stick around to participate in minute-by-minute delivery to users. Instead, the pre-created website files go to a web server that’s single-mindedly dedicated to the task of endlessly listening for requests and fulfilling them one after another with a transmission of the corresponding file. By the time any real world user visits a page on a static site, the original software that generated it is done with this process, and therefore cannot interact with visitors at all.
When I got started with making websites, this was the workflow for everyone involved:
- I write content for later inclusion or conversion into HTML
- Deliver files to server or storage system used by server (probably by FTP)
- User requests page from browser, browser requests page from server
- Server delivers file to user’s browser, browser displays or downloads file
- Repeat from step 4
Dynamic Features on “Static” Pages
Static Site Generators
There’s a class of web publishing tools that specialize in getting authors through the first step of making web-ready files after the necessarily human part is done. This saves an author the trouble of working through technical matters, so the author’s focus can be on producing content. Getting the files to a web server is sometimes feature of these systems, too. In some cases, the tool in question is already on the Internet, just waiting for your non-HTML content so it can neatly produce ugly-but-necessary files that look great in the browser.
Server Based Solutions
If you need your website users to be able to interact with your site while using the browser, some sort of machine needs to be ready and waiting to handle those needs.
When approaching the problem of choosing amongst numerous solutions it’s best to start by paring away as many options as possible.
I’m in love with Python as a language for expressing information for humans. If I open my mind to include the fondly cherished Python, I increase my list of fun trials by a reasonably vast extent, without going hopelessly overboard.