A Javascript Learning Expedition
GitHub "hosting" is the way*

GitHub "hosting" is the way*

Traditional hosting is lame

Matthew Reed's photo
Matthew Reed
·

5 min read

Before starting on my JavaScript learning journey, the following is how I got started with my general web development path.

  • I bought a domain

  • I bought hosting

  • I configured the settings on the domain name registrar to connect the domain to the hosting

  • I locally developed a portfolio "site" (a single page) largely in CSS and HTML

  • I used an FTP client to make changes to how the site appeared to the world

This is traditionally how it has been done. Seeing this now in writing makes the process and technologies seem very dated.

While I think FTP and traditional hosting still might have a place in the world (e.g. for large enterprise level sites), I also think on the scale of a personal site/portfolio, GitHub hosting is a viable choice, with some caveats.

Caveats

First and foremost is the relative difficulty in configuring (1) the repo's Pages settings, (2) the GitHub account level settings as to domains tied to the account*, and (3) the domain's own DNS settings.

It is a lot more involved and error prone than the DNS/FTP/hosting option.

Below are the some but not all of concerns that you should consider.

*Domain takeover

There are some dangerous pitfalls as described in the GitHub documentation on Pages and custom domains. Basically, if you don't configure this correctly, other people can do stuff using your domain.

No cPanel

Another concern, should you care about this sort of thing, might be in the lack of all of the tools provided by cPanel. cPanel is an advanced dashboard/settings tool usually bundled with most hosting plans. Both paid hosting and free hosting tend to offer cPanel.

cPanel itself offers many "things" to the user, including metrics, hotlink protection, IP blocking, SSH, and many others. Ultimately however, all of this stuff is probably totally unnecessary in the scope of a personal site/portfolio.

Lack of SQL databases

Another missing feature from hosting on GitHub is SQL databases. That is, you won't have any to work with if you host on GitHub. At least one SQL database is usually bundled with a traditional hosting plan.

However, in the scope of a personal site/portfolio, the user is probably not going to use a database anyway. This is thus an unnecessary feature.

No custom error pages (404, etc.)

This might matter for two reasons. One is more concerning than the other.

First, under "traditional hosting", by correctly configuring .htaccess (and by creating custom error pages in HTML and CSS), custom error pages can be made to be fun and/or pretty. The default Apache error pages can be alarming looking, though these days, these are rarely seen. In any case, making them fun/pretty is ideal over the default Apache error pages.

By hosting your site on GitHub however, you will not be able to utilize custom error pages.

Second--this is the more concerning thing--by hosting your site on GitHub, GitHub's own custom 404 page will be served as/if necessary. While GitHub's custom 404 page is styled and "pretty", a person visiting your portfolio not knowing it is hosted on GitHub might be confused when they somehow come across an error page with GitHub branding.

How or why a user would reach the error page is hard to say, and an entirely different question without a satisfying answer, but confusion may result nonetheless.

Takeaway

It seems it is not possible to set custom error pages when hosting on GitHub--even if you correctly configure .htaccess.

In any case, the implementation of custom error pages is a little more advanced than writing HTML, so the average person hosting their portfolio on GitHub may not even care about this (or even know it is possible to do such a thing).

No email*

Lastly a concern with hosting on GitHub is the lack of custom email addresses. Generally, traditional hosting provides the customer with at least one email address that they can send emails to and from. It will also generally provide a basic email management UI (think the gmail.com interface, but usually much more utilitarian).

Under, "traditional hosting", you can reference an email address on your portfolio page (e.g. hello@domain.com), and if that address is configured correctly in your hosting provider's settings, you can get emails at that address (and send emails as that address).

Luckily Google Domains offers the option to create an alias email address that will forward emails to any address of your choosing. Just set it up on Google Domains, and reference it on your portfolio page (e.g. hello@domain.com). Your domain registrar might offer something similar.

If you go with this route however (i.e. the "Google email alias" route), the person emailing you will eventually be able to see your actual email address (if/when you email them back).

Caveat to the caveats

This piece does not at all consider sites like Wix, Squarespace, and similar. In terms of "user friendly 'hosting'", these are obviously far better than GitHub. They of course come with their own "cons", in that the designs--though beautiful--are not your work.

tl;dr

In the scope of a personal portfolio "site", traditional hosting and virtually all of its features are overkill. Outside of this scope, traditional hosting is probably* the better choice.

function hostingChoiceDecider() {
  let choice;
  if (!wantsSquarespaceEtc && !wantsTraditionalHosting) {
    choice = "GitHub"
  } else if (!wantsSquarespaceEtc && !wantsGitHub) {
    choice = "Traditional hosting"
  } else {
    choice = "Squarespace or similar"
  }

  return choice;
}
hostingdnsGitHubGitHubPagesdomain