Live data from Hacker News

Hugo – Golang static site editor

gohugo.io

11–20 of 47 posts

Re: Hugo – Golang static site editor

#11
post #7

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…

> 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.

Re: Hugo – Golang static site editor

#12
It looks like it's basically a markdown to HTML translator, with a scheme for specifying formatting in YAML. It's almost easier to write HTML by hand.

(I still use Dreamweaver 8 for static pages. They render just fine with modern browsers.)

Re: Hugo – Golang static site editor

#13
post #12

It looks like it's basically a markdown to HTML translator, with a scheme for specifying formatting in YAML. It's almost easier to write HTML by hand. (I still use Dreamweaver 8 for static pages. They render just fine with modern browsers.)

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.

Re: Hugo – Golang static site editor

#14
post #10
post #7

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…

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.

> I know it's Go and it will likely be a single binary with no deps that just works.

It is and it does.

Re: Hugo – Golang static site editor

#15
post #12

It looks like it's basically a markdown to HTML translator, with a scheme for specifying formatting in YAML. It's almost easier to write HTML by hand. (I still use Dreamweaver 8 for static pages. They render just fine with modern browsers.)

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...

Re: Hugo – Golang static site editor

#16
I use hugo on my personal blog at the moment. http://utkarshsinha.com/

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.

Re: Hugo – Golang static site editor

#17
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.

Re: Hugo – Golang static site editor

#18
post #11
post #7

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…

> 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.

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.

Post reply on HN