Website Building on the Cheap and Easy

I threw together a website recently for the band I'm playing in. Much like a boat, a website is the sort of thing that you can spend as much as you want on, in terms of time and effort (and, obviously, money). But what if you'd rather do it quick and (almost) free?

There's a lot of ways to do that, turns out, but I found a pretty good one. There are only a few guaranteed requirements when putting a site together, and all of them are negotiable costs if you know what you're doing:

Domain Names

If you need your site to live on a unique top-level domain, like mycoolwebsite.com, there's no way around this - you'll have to pay money for it. There's quite a few services out there that will sell you domains and do the DNS hosting and such that comes along with that, usually for a flat yearly fee - it should absolutely not be more than about 25 bucks a year. I've been using namesilo which works fine.

If you don't need a distinct TLD, you can park on many subdomains for free - for example Github Pages will give you a URL like mycoolsite.github.io that you can serve your static HTML from, also for free. This is nice, because it's the cheapest way to get the other thing you'll need:

Hosting

Any content you are serving up has to be served up somewhere, from a physical machine (though commonly, it's a virtual machine running on a physical one). If you are just serving up HTML files and static content (javascript, css, images, etc), you can do that for free, as mentioned above, through Github Pages.

If you have to serve up dynamic content, you should first ask yourself whether that's really necessary. Static content is significantly easier to build and deploy, it gives a great UX (because it loads quickly, and looks the same everywhere) and it exposes almost zero attack surface to anything malicious. But if you must serve dynamic content (as in, render a response dynamically on the server-side before sending it to the client) you'll need to rent hosting for that.

I've used Heroku to do that in the past, though I cannot recommend them anymore after having an infuriating experience with their customer support department. There are many other cloud providers out there that serve dynamic content, and you have options all the way from a heavily on-rails experience with something like Azure Functions to just renting a VPS (virtual private server) which is a virtual machine you can run whatever you'd like on; there's a decent-looking guide here though I've never gone down that route myself.

The Bare Minimum

But enough about the fancy stuff. If you just want to get a static site up and running with a minimum of fuss and cost, here's what I did and would recommend:

• Set up a static site generator like Hugo (which I'm using, and quite happy with) to generate the content for you; this lets you write content in (for example) Markdown and output it into HTML pages without (mostly) having to mess around with raw HTML.
• Use something like a theme for your SSG to get the CSS and layout as close to what you want it to look like as possible. If you want to customize anything you'll still probably have to write a little CSS (I'm sorry) but CSS is the sort of thing that you should write as little as you can get away with.
• Set up your code in a Git repo, and deploy it to Github pages, ideally using a pre-existing workflow. If you're just outputting HTML files you can always find a way to copypaste them wherever they need to go but you want the process to be as effortless as possible.
• (If you want a domain name) buy one and get it set up with your Github Pages site. This is actually one of the most infuriating and time-consuming steps because DNS changes have a long delay in publishing (NameSilo only publishes updates every 15 minutes, for example, which sounds like it's unusually fast if anything) and then they take even longer to resolve through all the various layers of DNS cache scattered around the internet. Resolving DNS cache is especially frustrating because for example, you may be able to see the changes you've made when you check the records from your local machine, but your hosting provider may not, and they may just throw incomprehensible errors at you until the cache resolves. Fun times. So really, start this step early, and be prepared to wait for quite some time (hours or even days in the worst case scenario) before confirming any change you've made.
• Edit your content. If you've done things right it will be super easy to both test your changes on localhost and to deploy them live when ready.
• Profit.

The effort you'll have to put in is obviously a function of how much customization you want to do, but I put together a basic site with a few pages and some semi-customized design with this workflow in maybe 7 total hours of work. The only cost for me was the yearly registration of the domain name. So all that's pretty cool.