I do use Jekyll, but given that a site will live for a few years at least, babysitting a ruby app isn't something I look forward to. Maybe my server has a different ruby version from my desktop, maybe some ruby gems are installed by my distribution and some others I have to install manually via gem leading to an inconsistent system state, every now and then something breaks, some functionality is provided by a gem I have to install manually and oops, I forgot to ssh to my server and install it there too. Oh, some gems can't be build because my server is hardened. Maybe jekyll got a new version and this leads to new ruby adventures.
Hugo has some other niceties too, like a built-in server with live reload and some clever link translating while testing on localhost.
But docker also has its own complexities. A user that can run docker, is almost as good as a user with sudo rights. Would you give your CI system root access on your server? There are of course workarounds, like permit the CI system to run only the jekyll image by adjusting the sudoers file but, at some point you have to think about the scope of configuration needed for deploying your site.
Also docker on hardened servers can be challenging, for example I had to disable most of grsecurity's chroot protections to have docker run.
Actually, you will be missing things like the meta tags for an image preview when sharing the post on facebook and other sites. This still needs to be added.
Having a single binary that does that is easier to maintain than a script plus a stack of ever-changing dependencies.
I initially thought the comment was just about dependency hell, but now upon re-reading I find myself wondering what sort of (static site) setup requires both server and dev machine to share dependency state.
Maybe in the case of off-line testing before a push to remote?
Thanks for clarifying for me.
Deployment via CI is important, because you may don't want all your devs to have ssh/ftp credentials to the server, or maybe you want to be able to work from many computers, yet prefer to keep your server ssh keys in only one.
Another issue is that multiple developers can use different operating systems. To be honest I have no idea how to setup jekyll on OS X or Windows. For hugo I just say to my devs “download and run this file”.
If I had jekyll set up on my home environment, I could avoid that - but if the environment was different from github's, then I'd only be able to avoid it most of the time.
- Jekyll is a Ruby thing and requires you to have pretty much all the Ruby stack, including some kind of version manager like RVM. - Hugo is a binary that you can download and stick in ~/bin/. - Jekyll comes with Sass; Hugo comes with LiveReload. - You can extend Jekyll in Ruby. I wrote a thingy for Jekyll to generate breadcrumbs and color them based on a SHA hash of the page title; I don't think I could do this in Hugo without adding this sort of functionality to it myself and possibly submitting it upstream.
If I gave up my beloved auto-colorized breadcrumbs and moved to Hugo I'd still have to find a way to get Sass to execute on every Hugo rebuild, and there's still all the things I have Gulp do for production builds (autoprefix my CSS and minify the HTML). Seems like all programs in this space helpfully offer to be file-monitoring task runners, but I'd rather not have too many for what I think are simple sites.
In any case I'd think the drawback to this is the manual updating everytime, although overwriting a single file with curl/wget is probably not much more laborious than updating gems. And less likely to break. And wouldn't have dependency problems during the update.
.. you win this round rocky1138, but don't think this is over!
I've now moved it into Lambda, so to post a new page to my blog, I drop the markdown file in an S3 bucket, and literally a few seconds later my blog is updated, Cloudfront and all.
I couldn't get to CloudFormation template deploy working, so set it all up by hand, using the scripts in that repo as a base.
Once you figure out how it works, it becomes easy to start adding other commends to run (for example, I added some lines to invalidate CloudFront when I uploaded a blog post).
If I get a change over the next week or so I'll update a repo with the scripts I use, but as I said it's based on the above anyway.
But I'm also a heavy Hugo user.
For me speed is very important. And with Hugo's great live reload, the editing of content and styles while getting instant feedback in the browser, it doesn't get much better than that.
Hugo 0.17 was released two days ago with native multilingual support. Important for some bloggers, but a pretty huge thing for documentation sites.
Thanks, didn't know that, I might take another look at it then.
I mostly did it because it's faster and sometimes I like to waste time microoptimizing my website, but I don't there's any really good reason to switch your static site generator if you're happy.
1. Speed. Hugo generates my site in seconds instead of minutes.
2. Less dependency issues with Ruby.
I plan to clean up and package the code into a theme soon. In the meantime you can see it at https://github.com/hypertexthero/sgg
I keep seeing this question when a new technology pops up when in a crowded field there are already usual suspects out there. You shouldn't switch if all your problems are solved. Why would you?
My rule of thumb is that new technologies are for fresh projects to evaluate whether they are good fit or not. I haven't used any static site generators before so I'm open to this but if I had already invested in an ecosystem I wouldn't give it up for a similar feature set unless it's massively better.
I haven't used Jekyll, but I know of a very vibrant community that exists around it. I didn't go with it as I also read about the challenge of installing it on Windows. Although I prefer other OS's for myself, I feel that having Window support as well tends to result in fewer surprise down the road.
EDIT: Some grammar stuff.
I currently use it in place of Jekyll on github. I fought jekyll enough trying to get it to do what I wanted. Now I don't need to worry about it.
Another awesome feature: Since this is mostly used for personal sites and a lot of those are portfolio + blogs you have multiple "content type"s made by different folders. So you can show all your posts easily by iterating over the posts and then show all your projects by doing the same. They each can have separate default templates.
Odd. I found the exact same opposite. Granted, I have been using Jekyll for some time now and only tried Hugo for one afternoon. But I found Hugo very opinionated in how the site should be structured and it felt more like working with a CMS than with a static site.