4 ms·

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 Gi

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. [1]: http://fredrikloch.me/post/2014-08-12-Jekyll-and-its-alternatives-from-a-site-generation-point-of-view/ http://fredrikloch.me/post/2014-08-12-Jekyll-and-its-alterna... [2]: http://scottpatten.ca/2011/11/speeding-up-jekyll-generation.html http://scottpatten.ca/2011/11/speeding-up-jekyll-generation....

eloff 11y ago
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.
- jacquesm 11y ago
  > I know it's Go and it will likely be a single binary with no deps that just works. It is and it does.
  - sriku 11y ago
    It depends on python-pygments for syntax highlighting, though you can configure it to use front-end based highlighters like highlight.js.
    - spf13 11y ago
      It can optionally use python-pygments for syntax highlighting. It's not a requirement and as you mention alternatives are available.
tvon 11y ago
> You want to avoid dealing with Ruby, (...) 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.
- SomeCallMeTim 11y ago
  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.
  - TheDong 11y ago
    > Go is always awesome 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
senjindarashiva 11y ago
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

eloff 11y ago

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.

jacquesm 11y ago
> I know it's Go and it will likely be a single binary with no deps that just works. It is and it does.
- sriku 11y ago
  It depends on python-pygments for syntax highlighting, though you can configure it to use front-end based highlighters like highlight.js.
  - spf13 11y ago
    It can optionally use python-pygments for syntax highlighting. It's not a requirement and as you mention alternatives are available.

tvon 11y ago

> You want to avoid dealing with Ruby, (...) 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.

SomeCallMeTim 11y ago
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.
- TheDong 11y ago
  > Go is always awesome 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

senjindarashiva 11y ago

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