I would humbly suggest that static site generators are not nearly as popular as you might think if you only view the CMS market through the eyes of the HN crowd.
SSGs are hugely popular among nerds and practically unknown among everybody else. The result is a kind of distortion where, to nerds, it looks like SSGs are about to take over the world -- "all my friends use them!" But step outside that tight network of people and they are more or less completely off the radar.
I agree - I find the idea of static site generators (SSGs) very appealing, but they are not user-friendly to setup - unless you happen to be technically-minded. Some tell-tale signs that SSGs are made by programmers for other programmers: command line-installation and configuration, a liking for markdown (and a dislike for WYSIWYG).
Just to be clear, I'm not knocking any of this. The fact that people have put their own time and effort into building SSGs and then generously open sourced them is pretty awesome.
In my view, the audience for SSGs, whether intentional or not, is mostly other programmers. What would it take to make an SSG appeal to a broader set of users?
I'd agree with your assessment. We're testing an SSG with an international website to see what the experience is like. We've traditionally used Drupal, although we use almost zero of the CMS-functionality of Drupal (hence why we were looking at SSGs). We're using Hexo for this deploy. Here's what we've found:
- For complex web pages with a lot of design, we have to put most of the content into .jade files - mainly because of the style of our webpages (long-single-page style with a lot of sections). If we were doing a more traditional page structure, then we could have markdown files. This is "ok" but requires content authors to get into .jade files which can be a little intimating. (if anyone has any thoughts about how to get around this, I'm open to hear them).
- We're storing the files in Github, but have now figured out that if we want a distributed team to work on this, we'll need something like Jenkins to auto-deploy to a staging server on commit. The problem is that the first thing people want to do once they've made an edit check the page to see if it worked. This is trivial in WP or Drupal, but without Jenkins in place, I don't see an obvious way to do it unless we have the content folks run Hexo locally (which I'd like to avoid).
- Huge improvement in the speed of the site vs. the Drupal website. Not shocking given the move to static files, but there is also a reduction in javascript - some of which was coming from Drupal.
- Nice to have all content under source control.
All in all, it's a bit of a mixed bag at the moment - the SSG is supposed to be a simplification of our stack, but now we have to run Jenkins to manage deploy (probably not a bad thing but no one here is an expert in it), and our content people are finding it a bit intimidating.
My worry: we setup all this stuff, and then someone key on the engineering team leaves and we're left with an overly complex stack vs. just going with Wordpress.
> What would it take to make an SSG appeal to a broader set of users?
I don't think the SSG, as they largely exist today, will ever gain widespread usage by mainstream users.
But one thing that could drive greater adoption would be to develop an aesthetically pleasing web front-end that lets users write content using familiar WYSIWYG tools, but save the content to local files instead of a database. From there, the process would be largely the same as it is now: transform this directory of lightly marked up plain text files into raw HTML.
So, to answer your question: Make it more like Wordpress.
There is no doubt that SSGs will "grow up" and appear to gain features like Wordpress. The difference will be that SSGs are born out of loosely coupled tools in a toolchain ecosystem. Over time, I believe the successful SSGs will have a decidedly Unix flavor to them. Take http://www.metalsmith.io/ as an example.
I think the future of "SSGs" is that they're going to end up as programs running on the server that watch data from various feeds - databases, RSS feeds, APIs - and generate output from those. Basically, a streaming processor framework. The output would likely be in a "semi-baked" format so that they can contain processing instructions that are executed at request time, or otherwise lazily.
These won't be static site generators any more, and will lose out on the "you can throw it up on Github Pages" benefit, but they'll be far more powerful, and it'll be easier to develop dynamic, data-driven websites.
SSGs are hugely popular among nerds and practically unknown among everybody else. The result is a kind of distortion where, to nerds, it looks like SSGs are about to take over the world -- "all my friends use them!" But step outside that tight network of people and they are more or less completely off the radar.