We’re moving house soon, and we’re planning to rent out the flat we live in now. We could use an estate agent, and get the flat up on all the usual property boards. But, in the spirit of the IndieWeb, and because we don’t want to pay commission to agents, we decided to put up our own website advertising the flat.
As with most developers, as soon as I had the idea of a project, my mind was racing with possibilities, and I had to stop myself from jumping straight into a code editor.
What technology will we use?
Whenever a web project starts, this is one of the most fundamental questions to answer. Until you’ve decided this, you can’t get very far with building the thing.
A lot of developers will default to their standard toolkit. We tend to use what we’ve used before, what we’re comfortable with. Most of the sites I’ve built over the last few years have used Drupal. For a while I used to choose Wordpress for smaller, simpler sites, and Drupal for anything that needed more flexibility and complexity, but as I got more familiar with Drupal, I became more efficient with it, to the point where it was quicker and easier to use Drupal.
Besides, often those smaller sites will end up evolving into something more complex, and with Drupal it’s fairly straightforward to set the CMS up so that it isn’t too intimidating to the editors. In my mind, that leaves the ease of updates as the only thing in favour of Wordpress, and that’s a double-edged sword if people don’t test updates properly.
But it’s important to remember that developer convenience shouldn’t be the deciding factor in how you approach a project. Your technology choice should be guided by the needs of the project and its stakeholders.
Does the site even need a CMS?
There are two questions I’d always ask when planning a project:
- How often is the content going to be updated?
- Who’s going to be updating it?
Content management systems are very useful and very powerful, but they bring additional complexity with them. You have to make sure that the software and the server it’s running on are configured correctly, and that they’re kept up to date. The more you can reduce the complexity, the fewer challenges you’ll have.
These days, for simple sites, I’d be more inclined to use a static site generator like Jekyll, as long as the people editing the content would be able to handle writing in Markdown. Security and performance both get a lot easier to handle if you’re just serving flat files.
For this project, the content is hardly ever going to change, and when it does, it will be me who edits it, and I’m comfortable editing raw HTML. So no, we don’t need a CMS. And because there’s only enough content to fill a single page, we don’t even need any kind of site generator. Just a single HTML file, with some CSS and JavaScript - keep things as simple as possible.
Where do we start?
No matter how complex your project, there’s always the option of starting from a completely blank slate, but unless what you’re doing is very bespoke, do you really need to roll your own every single time? The problems that you’re likely to face in a web project are almost certainly problems that somebody else has already solved, so why not stand on the shoulders of giants?
Having decided to build a single page site, I found a single page template based on Bootstrap that looked OK. Bootstrap and Foundation are often criticised for contributing to a culture where a lot of websites look the same, and perhaps rightly so. But a lot of the time, the people who publish content websites don’t want or need their site to be unique. There’s a reason why a lot of startups use these frameworks - they want to get something out there quickly, so that they can show the market what they’ve got, so that they can get some income and start iterating.
Yes, I feel a little lazy for spending five minutes googling single page templates, but what would be the value for me of doing something else? Perhaps I could use this side project as a learning opportunity? A chance to try out a new technology, or a new way of doing things?
Those can be good reasons to choose a technology, especially for a personal project, but I wanted to get a basic site together quickly. I wanted it to be good enough with minimal effort on my part. By starting with a template, I very quickly had something presentable enough to start showing to people. If I’d started from an empty file, perhaps I would have built something with more of myself in it, something I could be more proud of, but it would have taken a lot longer. Moving house is stressful, and I’ve got a day job and a family, and a bunch of other things on the go, so I didn’t want to spend enormous amounts of time on this.
In short, I had a fairly clear idea of my minimum viable product, and using a template meant that I was quickly able to reach the point where I could focus on the content. After all, the content should always be the main thing.
Being a developer, I’m always looking for things to improve. For instance, perhaps I could get the site loading faster by converting FontAwesome to inline SVG, or maybe I could do something clever with the images or critical CSS.
But the point is that the website isn’t there to impress other developers - it’s there to get a message out to the world - that we’re looking for someone to rent our flat.