What's with all the static?
Posted on Sun 21 May 2017 in Web
Or how I learned to stop loving the database
If you are like me you probably spent a good part of the 2000's dealing in php CMS and blogging software. Wordpress for many, for me Drupal. Now don't get me wrong Drupal is a fine platform, but for 90% of what I needed to do, but it is overkill. This is especially true for a site where I am the maintainer, like this one.
I remember the early years of Drupal. It had less polish than some of the other competitors (Xoops, Mambo (Joomla wasn't out yet), and a few others), but it was amazingly customizable. This was especially true with it's ability for a webmaster to define custom content and views with basically no knowledge of php. Drupal truly was and is as the name implies community plumbing. An easy install on any LAMP stack setup made it workable for anyone with a modest VPS or even shared hosting.
All the things one might do to critique these platforms you end up in the other end with many sites of rolling your own. The only advantage to that is using a language you like better. I must confess I have never been fond of php. One of the reasons we turn to these engines is to make our lives easier with fitting all the pieces together and also when providing a site for a customer allowing them to be able to make their own edits and add their own content.
By today's web development standards they are like the saying about IBM. Indeed I think you can safely say that over the past 5 years no one got fired for choosing Drupal. They are safe and solid bets, but in many ways they aren't pushing new ground with other web trends. But who is going to code an Angular or React app and their own RESTful microservice back end just for a blog or the average website? No one sane unless they are learning and needed a non trivial project to work on for their educational purposes.
Enter the static website generators. Basically taking the tier of what it took Drupal did when it had to scale (aggressively cache everything) and just made the cache the site. You write, you generate, you publish. No need for the 30 some DB queries some Drupal or other CMS engines could initiate for some page views. Granted they are no CMS and they aren't really designed around multiple maintainers and editors working on the same content.
For me there became an oddly new piece of the static site generator of my choice (pelican) that became very satisfying. Other than proofing the site no need for GUI apps to work on it. Between the terminal and Emacs I could do everything I needed to for my site(s) easily. In other words I don't have to load up the browser to edit a page on my site. Fire up Emacs (which for me is always open), edit and write, and then use Fabric to publish. OK some may aptly point out that I just listed more steps in theory. But for me the speed and comfort of those steps to my other work flows is what makes the difference.
And although there are downsides to static site generators, and some things they aren't suited for I will give them 2 major pros over any dynamic CMS solution:
- Performance - because frankly at the end it is just static HTML, which is trivial for nginx to fire out on each request.
- Security - there is no injection point to really hack the site or change its behavior. Nothing done through the site opens up any writable access to anything.
I am too busy, and perhaps too lazy, to chase every new Drupal or Wordpress vulnerability or to spend all the time tweaking to find the right usability and performance balance in my cache settings these days. I just want to write, and publish, and know that it is all just working.
If any of this sounds like you go out there and try out a site generator in the language of your choice. I will put 3 out there now just to start your journey: