After many years I have updated my personal website. In the process I had to consider what might be the "right way" to build a site in the current era. This post will discuss different options, categorised under five headings.
I have been creating websites for almost as long as there has been a web. For many years I was CTO of a business that did things then thought impossible (namely, large data transfers and processing). For two years I wrote Perl scripts. I have many hours of server configuration in my distant past, now thankfully (mostly) forgotten.
I now require a simple, open, extensible, standards-based solution. I am technically capable and don't mind programming a solution. But any coding must be in Python, since other languages waste my time. (I trust that is partisan enough!)
I will now summarise five different website development methods, as I see them.
1. Static
This is the simplest way to create a website. Create the HTML, CSS, and Javascript manually. Combine with JPG graphics. Upload to any old web host. Done.
The downsides of this method soon become apparent: maintenance, repetition, and sheer drudgery.
2. Generated static
Desktop tools can automate some or all of the process. Templates can be used to provide a basic pattern for a set of web pages. Specific data then fills out each instance. Code modules can be added to provide extra functionality. But the end result is still a set of static HTML files that can be viewed from anywhere.
Back when there were few available solutions I wrote my own programme, Wasp. This app worked in two modes, one of which was generated static files. And I have been using it ever since!
3. Dynamic server, fixed structure
This includes blogging sites like Blogger and most "easy" web front-ends. Content is delivered from a web server using CGI, but the process is completely hidden. The user is responsible for the content, and can modify the visuals to a degree.
This blog is one example. It is written on Blogger, which makes the basic process of posting articles quite easy. But the customisations you see here are the result of many hours of hacking and deciphering secret tech. When I dive into the code now, I have no idea what is going on.
A bigger issue is that the solution is closed. When (not "if") the Blogger engine disappear, my site disappears... and migration may not be an option. The knowledge learnt in one proprietary system is not transferable to another. They are a poor investment.
4. Dynamic server, dynamic structure
This category includes Content Management Systems (CMS), which range from the simple and cheap (Wordpress) to the complicated and terribly expensive (many corporate solutions). These provide a great deal of control over the structure and look of your website, and also easy methods to enter content.
This flexibility requires an increased commitment of time and effort. The same comments as above regarding the proprietary nature apply.
It's a given that a CMS option places constraints on server requirements and is often associated with increased monthly costs. It also restricts the choice of hosts. But these days the most popular solutions are supported by a variety of vendors.
I have developed client sites in Textpattern, which is open and free. Years later, these sites are still functional, but eventually will fade. All sites require maintenance as the underlying software versions change.
A CMS is a complicated beast. If you are building sites for a living, the investment you make in learning one might well pay off. Your customisations will be re-used often enough to be worth the time it takes to develop them.
But this isn't the case if you're using a system only occasionally. You will never remember all the little techniques and "gotchas". (That's why there's a thriving industry of Wordpress consultants.)
5. Dynamic framework
These code skeletons provide hooks into the web server and some useful scaffolding. They incorporate a CGI interface, so that dynamic websites can be served from Apache and the like. They assume that you have considerable programming skills, since you will be coding your own website structure and functionality.
My own Wasp was a workable solution. But it was made in an era when standard interfaces like WSGI did not even exist. It is out-dated and inferior to contemporary tools.
Comparing CMS
I spent a good deal of time evaluating the Python-based CMS solutions, but I am only going to present a summary here. The complexity of these systems, each with their own terminologies and assumptions, makes any comparison time-consuming and potentially error-prone.
The biggest issue is the amount of commitment necessary to properly review a product. Something simple and flexible at first glance may turn out to have hidden limitations.
We can break a CMS down to three areas of functionality: the templating system, data layer, and coding framework.
I am picky about templating. Certain products, typified by CherryPy, use "Pythonic" templating. What this means is that you mix in your code with your HTML template. To me this is a bad idea. Anything in a template should look like HTML (or meta-HTML). The Python code should stay in the code engine. This is doubly true in team development, where one expects a division of labour between the designer and programmer.
However, pragmatics comes into play. Sometimes it is easier to put logic in the template. A good solution will not
require this but will
support it.
Luckily, the situation in the last few years has stabilised and it seems that
Jinja is the winner. This clear and powerful templating language is used in all of the CMS that made my final cut. The same was not true even a year ago, so be wary of reviews on the internet that are stale.
When it comes to the data, some products (eg. Django) bundle in an Object Relational Mapper (ORM), which is a way of translating from object-oriented code to set-oriented information in a database. My experience with these has been tainted, since they are terribly inefficient for large data sets. But for a website I am sure they are just fine. Nonetheless, I prefer that simpler options are also available.
Some coding frameworks are massive and bundle in as much functionality as possible (
Django). Others are minimal and expect the developer to fill in the rest (Flask, Pyramid). I prefer the latter approach, since I won't be trapped by pre-made decisions.
This is true even if there is a rich ecosystem of developed plugins. There are several problems with using a plugin to add functionality. First, the plugin architecture itself my be restrictive or require excessive cognitive overhead. Second, you have just added a point of weakness, especially when it comes to security (Wordpress, cough). Third, you now rely on the plugin developer for timely updates as the main system evolves.
I will spare you further details of the forty or so systems I investigated. For me,
Flask would be the system I'd choose when developing a dynamic website. But I'd keep an eye on
Pyramid as well.
However...
Reconsidering
For a personal site, do I need dynamic content? Well, what does it have to do? (
Have a look.)
I need to display a snazzy home page incorporating a couple hundred informative entries on my various activities. I want to filter these articles by category and show related articles for each, based on tags. The articles need to be sorted in reverse chronology, like a blog. And I will be adding more all the time.
So, yes, it does at first
seem like dynamic content is needed.
But, in fact, all of this can actually be done with static files. The different views of the data can all be determined ahead of time (so long as there are not too many). Certain changing content can be provided on the front-end using Javascript, without requiring server-side actions.
What is needed is a darned good static site generator.
So I wrote one.
(To be continued.)
