Why should I switch to this from Jekyll. There are dozens of site generators and when I go to their websites they all hash over the same set of features. Can anyone has used both or any other site generators please let me know what you found the differences to be?
My main reason, as funny as it may sound, is that it has one static binary.
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.
I just last weekend revived a Jekyll site that had sat dormant for 3+ years and experienced exactly what you're describing. Not a fun afternoon. I do feel fortunate it was only _an_ afternoon, though.
I've been using the official Docker image for Jekyll (https://hub.docker.com/r/jekyll/jekyll/), which makes it fairly easy to avoid this particular problem. Assuming you're willing/able to have a dependency on Docker.
I am all for docker, we use it on production and I maintain a couple docker github repos.
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.
From the example in the Github repo I understand that the JS only compiles the Markdown to HTML. All the content is still being served on the server-side and the client only handles the way it's presented. If I'm correct, I see no reason why it should hurt SEO. All the content is still being crawled.
It's actually the most SEO friendly engine there is because there is nothing but content with Jr.
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.
I think many have a setup where the server grabs your website repo and creates your site. It's generally good to create your static files directly from your actual repo, whether that's on the host server or an artifact builder, etc.
The obvious thing that jumps to mind is CI/CD systems like Travis and Gitlab CI. The workflow for a lot of folks is to push to a git endpoint and then have the site picked up and then compiled automatically, rather than building on the dev machine then pushing.
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?
Yes, my workflow is localhost development and testing, then pushing to a git repo and call via a hook a CI system which is used for both deployment and validation that the code works in a vanilla/reproducable environment.
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”.
Yes. When I write for my github pages blog, my edit-compile-debug cycle includes pushing to github and seeing how my post is rendered. I often get several minor edit pushes in a row.
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.
I use Jekyll for my main site and Hugo for a couple one-off sites that maybe ten people will ever see. From what I've seen:
- 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.
Your `/bin` technique works for Windows as well. I run Hugo for a couple of simple sites from a Windows machine. To do this, simply copy hugo.exe to C:\Windows and call it a day.
You'd be better having it out of the OS directory and a path reference surely, no?
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 have moved from Jekyll to Hugo. Functionally it's the same for my use case, but in a single binary, meaning I don't have to maintain a full Ruby stack.
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 too would love to read a write up. I've just recently moved a lot of things over to AWS (from a traditional VPS) and having hugo in Lambda would be the last piece of the S3+Cloudfront cake.
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.
Use what makes you happy/gets the job done. I'm bep and one of the Hugo core devs, so I'm biased.
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.
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.
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.
Decent-looking, free themes to get started with: http://themes.gohugo.io/. This probably doesn't make a big difference for you, since you already have sites made with Jekyll.
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.
Jekyll's workflow is horrible compared to Hugo. A single binary that explains mostly whats going wrong vs a crazy mix of ruby gems that need to be installed with a meta-package that is hard to find in the Github support docs.
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.
We do this for hugo (and any other build tool) at Netlify (https://www.netlify.com) together with a whole bunch of extra features to make the workflow even easier.
On GitHub Pages, GitHub will run a basic Jekyll for you -> you don't have to install or run it locally, just edit the source files in the repo and it builds and publishes the page for you.
I tried, but for some reason I just kept going back to Jekyll, the community is so good, it's so simple, it just works. I think Hugo probably is as good but it's likely what you start with.
