Yichen's Coding Notes

Some experience and complains ;D

Blog / Coding
2020-07-11

Some Understandings of Personal Static Blog

My own personal blog has been established for a month. Everyday I've been considering: what else is worth improving. All the way until now, I would really like to write something down to draw myself some conclusions, for how a personal blog is working.

I'm definitely not professional at this and I might make mistakes in what I write below, but still let me share some information.

  • This site is hosted on GitHub Pages, but is not employing any third-party deployer, such as Jekyll.
  • The HTML framework (i.e. color, font theme and page layout) is modified from a free theme called ION from Templated, which is distributed under CC license.
  • Everything else you cannot find from the ION's demo page is manually added and debugged by myself.
  • New posts are deployed locally using my own script.

Building a Blog IS Generating some webpages

This is straight forward. The blog, can even be only one page written with: <html><body><p>Hi</p></body></html> as long as you think it is passing what you want.

Of course, everyone interested in having a blog has something (s)he wants to show the world. Then how satisfying webpages are generated becomes the key to discuss.

Who Generates the Pages

There are various ways to generate webpages. The first key difference I want to mention is how much is written by yourself and how much is written by automated programs. If you are planning to have a blog where you want to update new posts like a diary, this would mean that there will be an unknown number of pages to generate, and this number is hopefully to be quite large. Thus you don't want to manually type the HTML script letter by letter every time you want to update, because that will be way more than what is there in the "dry" content of your articles.

I would say, the baseline is:

Every time you post something new, you only write the article itself. And then let something else to insert the text into a template of the post page. And you should not do any further modification on the outcome.

Being clear of this point, then the discussion goes to who generate the other parts than the dry articles.

Jekyll, as an example, is a widely used user friendly deployer. I tried it at first. How it works is you write your articles in Markdown format, push them to the Git repository of your blog, and it will then generate a page for each of your post, using the theme and other configuration which you specified in advance. What you only need to worry about is, writing articles of good quality and choosing a theme that looks the best to you.

My own blog, as mentiond in the beginning, is deployed by my own script. My script also read my Markdown posts and generate pages for them. One of the differences is, the template page I use can be freely designed. I might have also achieve something similar with the Jekyll solution, but directly debugging on my local limits me less, which makes me, as a DIY player, feel much better.

When And Where the Pages Are Deployed

Since GitHub Pages hosts only static web sites, so it is impossible to generate any web page on server side.

Processing web pages on server side is something like:
You call a URL in your browser and your machine will send a request to a remote server. A program on the server parses the request you send, dynamically generates a webpage according to your request as well as other conditions, and THEN the generated webpage is sent back to your local.

Usually, the content of a static site is all prepared before they are ready for your request. That is to say, you have to submit the thing that the server-side program returns, because the server does not allow any program to be run.

With using GitHub Pages, there can be four stages:

  1. Before you submit your content to the host (i.e. GitHub)
  2. After you submit your content, but before the site is ready to be requested
  3. After the site is ready, but before some one requests
  4. After the site is requested

Note that everything you can literally see is displayed by your browser, who reads the HTML, JavaScript and CSS requested from remote to finally presents the fonts, colors and geometric patterns. Through anyway this would only be completed in the 4th stage. So this process will not be discussed.

Most of the solutions you can find on the Internet will tell you that a static site is finished within the first two stages. As you might have already understood, my blog pages are finished in the 1st stage. Websites deployed by Jekyll is finished in the 2nd stage. According to the definition of a static site, nothing can happen in the 3rd stage. But what about the 4th? It is worth being discussed, otherwise I don't list it there.

Yes, before the version of my blog you can see now, I actually did have a "wicked" implementation - the pages are finished in the 4th stage. During that version, I submit Markdown files and post templates - HTML document that has everything but the article content. When my site is requested, the client side (the browser that recieves a webpage) only recieves the template. After this, some JavaScripts embeded with the template starts working . These JavaScript codes again send request to the server, secretly, for the dry article contents. And finally the JavaScript codes arrange the contents and insert them to the template already there.

The reason I abandoned this strategy is that, since there are no content on cloud, my site cannot be found by Google search.

Jul, 11th, 2020


Last Next

Comments