I started looking into Hugo as a faster alternative to Jekyll. Two reasons why you'd disregard the fact that Hugo doesn't have the same support as Jekyll on GitHub pages:
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.
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.
It is awesome to be able to build a binary with go.
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.
If you need to build a version of master, or the project doesn't provide a static binary, or you don't wish to trust some random binary on the internet, or you wish to package a Go binary, it suddenly becomes terrible.
1. Build a version of master -- Go does not have a way to version or lock dependencies, so it's possible master will only build on the developers machine. The state of the art solution for that is vendoring, but each vendoring tool behaves slightly different, and even that results in some hell. It's not fun.
2. No static binary -- See 1, except now you're supposed to use 'go get' which is one of the most error-prone pieces of shit I've ever seen. It won't work with vendoring, so have fun.
3. Don't trust a random binary on the internet -- See 1 or 4
4. Package for a distro -- Good luck packaging go well. The informal ad-hoc dependency mess ensures that properly packaging go is almost impossible. The vendoring tools means you'll have hell modeling dependencies so you can react to security issues. Basically, your life will suck.
Ruby and NodeJS have none of those problems. To build a version of master, you have a gemfile / package.json that, if it follows specifications, will correctly tell you everything, down to the version, that should be installed.
Distros have tons of tools for packaging those languages and modeling them well. It works and is usually easy.
There's a single distribution method (npm / rubygems) so you don't have to check if there's a site with a curl | bash script, or a static binary download, or a github release page, or some other strange situation.
> NodeJS also has a larger pool of experienced developers
Citation needed. I have no qualm with the "larger pool" bit which very well could be true, but "experienced" and "NodeJS" don't go together so often in my book
>To build a version of master, you have a gemfile / package.json that, if it follows specifications, will correctly tell you everything, down to the version, that should be installed.
You can set specific versions, but the default behavior is to do >= or ~ versions, at least in Node. But you could potentially go in and change the references to =version# to get a version closer to the one the developer built -- but even then there's no guarantee that the latest build hasn't had a more recent download of the packages, with newer versions than those specified in package.json.
But I didn't know this about go package importing. I'm a bit disappointed that they didn't at least make it possible to import @ a particular hash.
You could look at the last check-in and pull versions of each of the dependent repos as of that date, if the latest builds don't work.
>"experienced" and "NodeJS" don't go together so often in my book
Touche.
But I've encountered similar issues with Ruby, TBH (allegedly senior developers who turn out to be slow and not as experienced as I had hoped), and it happens that the JavaScript developers I have around me seem stronger than the Ruby developers. But more and more developers are training every year; I read one article that alleged that junior developers outnumber senior by a factor of something like 18-1 at this point. So I'm statistically likely to be surrounded by an insulating layer of junior developers no matter the language I choose. :)
If I type "npm install --save foo", it gives me "^1.2.3" which says "everything compatible with the current version".
If you don't follow semver specification and make incompatible changes, well, :(
You also have the wonderful npm shrinkwrap command (https://docs.npmjs.com/cli/shrinkwrap) which locks you down similar to a Gemfile.lock, but inline with how the npm world works.
Thanks for tooting your horn about being senior while also being factually incorrect about the default behavior of node and not knowing you can use shrinkwrap to leave the loose version specifications but also commit what they actually resolved to on your machine.
I installed and played with Jekyll on a windows box. It was a horrible experience because of installing Ruby and all the dependencies. I'd like to give Hugo a shot just because I know it's Go and it will likely be a single binary with no deps that just works.
Thanks for linking my post (the [1]), Id like to add an issue to this though. A few of the latest updates (0.11 seems to have been the fastest so far) to Hugo have made the build time significantly slower, moving it closer to Jekyll. I've yet to test 0.15 though which hopefully improves the performance of Hugo again
I'll second these comments about Hugo. I use it with my business website (http://www.optimojoe.com/) and have been extremely happy. As a couple more comments:
- 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.
Likewise but I use gulp and the awspublish plugin to get things to S3. This way I can easily push a non-minified non-ulgified version to a staging s3 bucket to test/debug and then a minified, uglified, gzipped, long cacheTime version to my 'production' bucket when I'm happy (which also uses Cloudfront mostly just for the SSL).
Useful insight, thanks. Heads up your business website has an invalid link - "Products" is missing a slash and currently points to http://www.optimojoe.comproducts
I found Hugo too complex, so I wrote my own static site generator in Golang. I also didn't like that I couldn't get commonnmark to run simultaneously, so I use `make` & yes it's fast and easy on my brain.
https://github.com/kaihendry/natalian
Hugo is awesome, especially because of the speed of builds. We use it with netlify for https://www.staticwebtech.com and it generally takes around 5 seconds from we push to git and until a new version of the site is live.
I just tried to make a Hugo website and it was easy. I don't think it is super important, but you can't not notice how fast it is.
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.
Just migrated my blog to Hugo. I host my blog on s3 directly, so the most time consuming step in the chain is uploading to S3. Stout and surge are nice pointers (thanks).
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.
I briefly reviewed some static site frameworks and found that Hugo was one of the few that supported complex taxonomies. Anyone had any experience with more complicated sites?
Hugo is a great tool with a very responsive dev team and friendly community.
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.
This is actually what I am using now on my personal blog (https://brock.io)
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.
I am currently using it for my blog at https://kaushalsubedi.com/ and as someone who just switched from WordPress, the difference is night and day. I threw the site in a CDN and everything loads almost instantly since its all static.
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.
FYI: Hugo has won the static site builder / generator of the year 2015 award (in the alternative category) -> https://twitter.com/viennahtml/status/669540918714695680 Congrats. PS: In the ruby category the winner is Jekyll and in javascript the winner is Metalsmith. Cheers.
People are claiming it is fast but based on what ? faster development, run time, concurrency, async parallel task handling, based on which parameter you can say it is fast ? is it noticeable for small scale project ?
Huh, interesting. Doesn't seem to spend any effort on only updating things that need to be updated, but just tries to be fast enough that it doesn't matter if it redoes everything?
That approach doesn't look so good once it has to do expensive tasks, like image processing, but for HTML generation it seems to work.
I recently started to use Hugo for a not yet done static website I'm working on, I must say I enjoy it. I haven't deployed the site or anything yet since I'm merely experimenting. I kept trying static site generator scripts in Python 2 / Python 3 but they seem to fail for me for one reason or another.
I am using Hugo on my personal site http://www.gntech.se and i Like it alot! Coming from Jekyll and Pelican I really appreciate the build speed and the minimal environment setup that is needed! Highly recommended tool!
Is the speed really that much of a problem? About 90% of all SSG-based blogs I've seen contain about half a dozen posts, as switching/using a SSG was basically the reason someone got (back) into blogging. And then abandoned it six months later.
It's easier to write HTML by hand if you only have a few pages. But if you have a few hundred or a few thousand pages a site generator can save you a lot of time and sometimes your sanity.
Apart from that, separating content and design can also be a big deal for working with different kinds of tooling.
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...
Oh wow, I just looked up their doco, and found the csv and rest connectors. Thank you so much for this. Had I known I may not have built a recent parts database website with harp.js and a weird mashup of php, bash and even a go sitemap script. Dumping out csv files from excel, iterate through said csv files with php and dump ejs files with part (628 in all) then harp compile followed by an s3 sync for all 633 pages on the site. All scripts referenced from one bash file. I felt clever! But won't feel clever when I rebuild my Mac with X number of environments (npm, php, aws sdk, OSG) to build the site. With Hugo and also stout [1] also mentioned here, the workflow is alot more predictable, and binaries could be kept in the project for easy portability.
Also worth mentioning is OSG [2], a sitemap generator written in go that I use in my bash script. It's very fast. This may have some advantages over hugos built in sitemap generator depending on your site, though I think I would use hugos in most cases. Might be useful for others using other static generators that don't support sitemaps and also have other CMS's and carts / forums installed too.
You're welcome! And give netlify a try (I'm a founder). For a large site with hundreds of interlinked pages, S3 has the problem that there's no good way to do atomic deploys (what they call all-or-nothing consistency for whole deploys in the stout documentation).
Netlify will make sure you get true atomic deploys where no changes go live before all changes have been uploaded and handles instant cache invalidation.
We have built-in support for hugo for our integrated continuous deployment system, and can do builds triggered by webhooks. So for any setup where you're building based on external files, you can easily trigger rebuilds whenever one of those datasources gets updates...
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.)