Static website generators are a new way of managing your website. A tad nerdy, a tad complex. Certainly with a very unique touch. Here is a little site I created using Hexo – more on Hexo later: log2talk.com.
Partially, maybe. The actual reason however is that “traditional” CMS, as powerful as they are – and there is a reason why WordPress accounts for 27% of all website CMS! – are not friendly for programmatic access. Just try to roll out a whole new website as part of one deployment script that might be worked on by any numbers of people simultaneously, residing in a code repository like GitHub. That is not the traditional way of managing a website – there are usually several people involved in publishing just anything. Let alone e.g. creating a new flavor of an existing site by issuing terminal commands. Since most development teams nowadays work that way that kind of approach translated to managing a website certainly has its appeal.
To the developer community, that is. If you are running a site for the sake of focusing on the content then that is the first thing to realize: you will only gain convenience, speed by using static site generators if you have a development acumen. Otherwise there is a steep learning curve ahead, certainly not comparable to easily getting going with e.g. WordPress.
So I tried it myself and created a Hexo generated site that is being built and managed by Netlify, a platform that supports the build of static websites like no other I have seen. You have to have your GIT repository, choose a content generator, specify the parameters you want or just keep the defaults – and the rest is just about getting the website skeleton pushed to GitHub. Netlify would take over from there and get it all deployed, distributed via its own CDN. So yes, it performs well. Hexo is is written in NodeJS and works perfectly fine in my favorite IDE Cloud9, so you can get started without ever leaving your browser and run as well the “development server” there for checking what you have done before you push any changes. The thing to get used to is that you would have to clean and re-build the static files every now and then for bigger changes in order to see the changes reflected. (Reminds me of debugging Java code.)
Hexo comes with plenty of nice features and a rich set of themes to choose from. Clone a theme into your site folder – and of course those themes would sit in GitHub like pretty much anything else you will be working with – and you are almost done. There are some configurations you can do for your basic site and the theme and probably you will have to, yet it’s not necessary to get started.
Another thing to get used to is that you articles will have to be written in Markdown. Did I mention that static content generators are geared towards developers?
Now you wonder, what to do about the dynamic contents that your site requires? Form captures and what not. Don’t you need servers for that? Well, no. The new-school way of thinking about that is to go serverless and rely on the capabilities of the clouds. Here is a nice article about how to create your serverless file uploads. And then of course there would be SAAS solutions for these kind of tasks that take everything away for some fee, to go down the super lazy lane.
So that is all nice and dandy, yet what is the bottom line? Should you go static site generator?
For me I have to say it’s fun because of the additional burden of “mastering” Hexo, slightly exaggerating. It’s certainly not for everyone and if your website is not part of ongoing builds then the big question really is what the reason would be to manage your site that way. Once you have set everything up you will however enjoy a lot of nice features like asset optimizations (minimizing etc), easy management of SSL certificates right out of your terminal and things alike. Is that cool? I don’t think so. All in all there is no reason to consider serverless static generators the new way to go. It is just an alternative way of going. And to be frank, it is not even a new way: pre-rendering static assets is a technique that some CMS already applied years back and there are plenty of libraries e.g. for SpringBoot that can do it. Well! The choice is yours.