My pros and cons of Hugo:
+ It's fast.
+ Like, really, really fast. I'm looking at <1s builds for a couple thousand pages which took around 5-8s in Pelican.
+ A lot of really nice out-of-the-box stuff like markdownifying arbitrary strings, rss and sitemaps, etc.
+ Extensible front matter system. (I abuse it to stuff an arbitrary JSON object into each page.)
+ Did I mention how fast it was?
- Debugging is hell. Error messages are unintelligible and generally distract from whatever the actual issue is.
- The structure of a theme is sort of unintuitive, but that may be personal preference.
- Lack of support for more user-friendly templating languages like Jinja2 (this is likely due to speed, but I'd still like the options.)
1. You're dealing with thousands or more pages. Jekyll can be slow as heck passed a few hundreds of posts. Benchmarks [1] show that Hugo is way
2. You want to avoid dealing with Ruby. Honestly, every single time I have to install a Ruby app I end up wasting 30 minutes on nonsense (wrong version, dependency hell, ...).
There are many things you can try to improve the speed of your Jekyll site (avoid loops, use Javascript to load some elements/features, leverage some configuration tricks [2]), but Hugo is just flat out much faster and much easier to deploy.
[1]: http://fredrikloch.me/post/2014-08-12-Jekyll-and-its-alterna... [2]: http://scottpatten.ca/2011/11/speeding-up-jekyll-generation....
It annoys me when using a tool require a functional development environment for the ecosystem it is based upon. E.g., ruby-based tools install via 'gem' and node-based tools install via 'npm', both of which are potentially huge hassles.
A nice aspect of go-based tools is that you can always just download a binary.
But despite the recent Node major version upgrades, I've had almost no problems with npm, while I always seem to have issues with Ruby/gem installs.
Binaries with no dependencies still win for convenience, but even Go has an ecosystem of libraries to deal with if you need to rebuild something. So I see the three on a spectrum: Go is always awesome, NodeJS usually works (and often has a package that supports functionality that Go lacks), and Ruby consistently makes me sad.
NodeJS also has a larger pool of experienced developers, which isn't everything, but it can be important, depending on whether the project is something that I will want to eventually offload.
It is and it does.
A few things I've found interesting are:
- Getting the layout just right takes a bit of tinkering (I mean the layout, theme and include file locations - not the CSS).
- The `hugo` executable is just perfect. hugo server --watch is all you need (plus it's super fast!)
- Also, I'm not a Ruby person. I don't need a whole Ruby ecosystem working on my machine just to parse some markdown.
- Grab the repo https://github.com/spf13/hugoThemes and flip through the themes. Personally, I don't keep the repository in my Hugo project, but just have a soft link to the base directory. Then, the command `hugo server --theme=MyThemeHere`, let's me instantly see what my website looks like under a new theme.
- The ruby gem s3_website (https://github.com/laurilehmijoki/s3_website) lets me update my Amazon hosted website instantly. Basically, I just run `rm -rf ./public && hugo && s3_website push` after adding a new page and I'm done.
- In any case, like liquidmetal, I'm not a Ruby person, but I was able to easily modify the themes into something that worked well for me. I started using Hugo after running through the other popular static site generators and found Hugo the easiest to get up and running and maintain.
Here's a quick guide on settings up automated deploys with hugo and netlify: https://www.netlify.com/blog/2015/10/06/a-step-by-step-guide...
I am a ruby guy and I really like Middleman, but there are things to like about Hugo. I like how it can pull data files. What I am not sure and need to explore, with Middleman I can implement pulling of the data, I am not sure I could do this with Hugo, but on the other hand, it can pull CSV and JSON from remote, so that is good. Also, taxonomy looks nice, I can see how all this can be useful.
Overall I am pleasantly surprised how well it is done. Some syntax definitely looks weird, but it might be just that I need to adjust to it.
Really happy to discover something new. Excellent work.
I'm currently using a simple script that pulls together fossil, s3cmd and gnu parallel to send the content over to s3. Fossil is used to track what changed, s3cmd is the work horse and parallel uploads multiple files at a time.
The movie example is similar to what I am after: https://gohugo.io/taxonomies/overview/
I use it myself for a couple of sites and I hope that the team continues to get the recognition it deserves for creating such a useful bit of software.
Incidentally, the license has recently changed to the Apache 2.0 license so hopefully this will encourage even wider adoption/contribution.
I went with hugo because it is very fast, and I didn't need to install any dependencies locally or on my server.
I bought a theme from themeforest and converted it to a hugo theme. It was a great learning experience, but the docs on actually creating a theme were a bit thin.
Hugo compiles fast, and the templating system is easy to understand and modify. Only wish it had support for directly compiling it and pushing the changed files from last pushed version via SFTP or even FTP.
If you're interested in the beta, hit me up on twitter @_brianknapp.
(I still use Dreamweaver 8 for static pages. They render just fine with modern browsers.)
You can use hugo to fetch JSON, YAML or CSV data from remote URLs and use those data as part of the build process. And if you use local data files instead of HTML you can use a tool like netlify-cms (github.com/netlify/netlify-cms) to give end users an easy way to work with that structured data without ever touching text editors or the like...
And as jacquesm said, once you have a more complex site with lots of pages, you'll want to use partials, reuse content in different places (show a summary of an article on an index page, full article inside, small blurbs on the homepage, etc), and once you get there you really don't want to write HTML by hand...
