Freely Hosted Serverless Functionality with GitHub Pages and Javascript

Written by RobertLeeRead | Published 2016/08/24
Tech Story Tags: github | web-development | rapid-prototyping | javascript

TLDRvia the TL;DR App

Forgive me, gentle reader, if all of this is obvious and well-known. I have not seen it in writing. If that is merely my ignorance, enlighten me.

As some who produces free software and often prototypes very rapidly, I often seek a lightweight way to provide functionality.

Each year this gets easier and cheaper and the definition of lightweight ephemeralizes further.

One good way to produce such prototypes in 2016 is to us the feature called “GitHub Pages” offer by GitHub in conjunction with JavaScript to produce serverless, zero-dollar-cost, zero-deployment-cost web pages. GitHub Pages is effectively web-hosting service with very limited server-side computation offered free-of-charge by GitHub.

At one time, using JavaScript would have severely limited the kind of app that you can deliver in this way, but as Cannon.js and Three.js demonstrate, you can now give sophisticated functionality to a user using only their own ubiquitous commodity browser.

In the last years, I have produced a number of applications in this way:

This approach has become my go-to style of programming.

In a sense, the easiest way to experiment with this style is just to fork one of my repos on GitHub (or any other repo that uses the same style) and then hack out the functionality (and included JavaScript) which you don’t want. All of my code is released under the GPL.

Of course this copy-and-paste-and-excise style is likely to leave you with a messy codebase unless you are fastidious in your excision.

Here is a basic “How-To” that starts from an emptier point:

  • Create a GitHub account if you don’t have one (they are free),
  • Create a new repo,
  • Use the built-in capabilities offered by GitHub in the “settings” for the repo to automatically create “GitHub Pages”. You can also do this manually, but there are a few pitfalls in that, so use the automatic tool the first time you do it.
  • Choose a visual theme that works for you.
  • Test that you have a live, universally accessible public site by going to the GitHub URL given to you. It will likely be in the form: “https://YOURORG.github.io/YOURREPO”.
  • Test that you can control and edit the public page by removing some of the default text given to you by the GitHub automatic pages and pushing your local changes to your GitHub repo.
  • Cut out the rest of any GitHub-supplied HTML that you don’t want.
  • Go ahead and copy a sophisticated rendering packing of some kind into your repo and reference it from your html file. (Even better is to use a CDN when it is available so that you don’t have to duplicate the package for a prototyping experiment.) Packages which I have used in the past include: Bootstrap.js, JQuery.js, JQueryUI.js, Three.js, P2.js, Cannon.js. You may also end up using d3, which is both more and less than a rendering system.

At this point you should have a (potentially) responsive web app that is completely free, universally accessible, and can go so far as to render photorealistic scenes computed with a physics engine, or just has some nice buttons and text computed with JavaScript. Tremendous value and beauty can be created with just that.

At some point, you may need to offer your users the functionality associated with durable data: that is, the concept of a “session” specific to user A and differing from user B starts to become important. When that day finally arrives, you may be able to use browser-storage to implement it effectively.

Eventually, you may be forced into having a real database to maintain durable identities that persist over time and other functionality — but don’t do it until it is clear that it is needed to improve the user experience. Let the users drag you kicking and screaming into it. Until that happens, you don’t have to spend any money, and you don’t have to have the overhead and complexity of deploying and configuring a server.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!


Published by HackerNoon on 2016/08/24