Feature Wishlist for GitHub Pages

In a post that I wrote a couple of weeks ago, I waxed enthusiastic about GitHub Pages as a hosting service for static websites.

I thought to be fair, I should also communicate what I consider the biggest gaps in that service, as it exists today.

This list is an attempt to rank some of these gaps, (i) compared to up-and-coming static site services like netlify and (ii) compared to the broader world of Web publishing like Wordpress and Squarespace.


This section was added 2015-10-23.

Using a special gh-pages branch instead of a separate repo makes publishing on GitHub Pages unnecessarily complicated.

And the default domain at github.io means that generated sites have URLs which are quite different from their source repo at github.com.

Why can't GitHub Pages work more like wikis?

A repo on GitHub has a URL like https://github.com/jldec/pub-server.

The wiki (if there is one) lives at https://github.com/jldec/pub-server/wiki - easy!

Furtheremore, wikis have their own git repository at <id>/<main-repo>.wiki.git which you can clone and pull/commit/push on master. This wiki repository is open by default for other GitHub users to edit -- something you just can't do with your gh-pages branch.

GitHub Pages sites should behave the same way. Pages sites should have their own repo for the ouput HTML, with a URL in the same domain as the source repo.

Now you could start doing things like hosting a staging site visible only to collaborators, or previewing a new generated site on your desktop before publishing it (and without installing Jekyll first) -- but that's a topic for another blog post .

1. https

These days, because of attack vectors like ssl-stripping, I would argue that any site with a form should be running over https. It's not enough for only the form pages or post-urls to be encrypted. And with SNI, hosting HTTPS endpoints has become relatively inexpensive.

2. generic form handlers

Casual users don't require complex back-end services to handle forms for things like surveys and contact requests. Translating each form submit into an email, or collecting form-field contents into a spreadsheet is sufficient.

More complex multi-step forms such as those required for payments require custom-configured services (see proxy routes below).

3. private pages

Marking pages or directory paths or an entire site as private would be a high-value, low-cost feature for GitHub Pages, and would serve many use-cases.

Design agencies could publish previews for their customers to try out, or companies could create internal sites on accessible only to their employees.

Simple access control lists in a text file coupled with oauth would be a good start.

4. granular authz

For users to manage website content using 3rd-party tools with sites on GitHub Pages, those tools need to be able to write back to a GitHub repo without asking the owner for blanket write access to all their repos. 'Nuf said :)

5. more site generators

Language frameworks like JavaScript and React are rapidly picking up momentum.

Opening the door for alternative site generators to be run automatically when new content arrives in a repo (just like Jekyll) is important to keep the service attractive for developers who build sites with the latest tools.

6. proxy routes

In the past mobile browser users were unable to see or block the traffic between pages they visit and 3rd party tracking services (or services posing as something else, but collecting data nevertheless). This era is thankfully coming to end.

A better way for users to interact with websites they trust, is for all traffic to go back through the same HTTPS endpoint.

The role of a static hosting service in all this is to proxy those requests matching specific routes, and forward them to real-time services on the back-end.

7. online content editor

This is the elephant in the room when it comes to static site generators and GitHub Pages.

How to enable non-technical users to maintain content on an existing site? Until this gap is addressed, GitHub Pages will be limited to sites maintained exclusively by technical users.

The solution suggested by the little Edit button at the top-right is a start in this direction.

pub-server includes an editor+generator which can run in users' browsers, allowing instant preview without round-trips to a server.

For more information visit the pub-server repo on github.

Thank you GitHub!

powered by pub-server and pub-theme-pubblog