7 ms·

Hugo: A Fast And Flexible Static Site Generator Built In GoLang

99 points by spf13 13y ago

vanderZwan 13y ago
Dammit, already taken: http://hugo.neocities.org/ http://hugo.neocities.org/ Would have been such a nice fit.
- deleted 13y ago
  [deleted]
piranha 13y ago
Well, here is mine: https://github.com/piranha/gostatic https://github.com/piranha/gostatic Unfortunately it has no pretty documentation, only README on Github. On the other hand, Hugo seems to have a bit more hardcoded configuration, while gostatic was written with 'whatever you want' idea in mind and is (maybe, I just skimmed though Hugo docs) a bit more tech-savvy people oriented. Anyway, it would be interesting to compare performance. :)
- spf13 13y ago
  I hadn't seen yours before. It looks good as well. I'd agree that Hugo is more opinionated (but not as opinionated as jekyll) and aimed at a broader audience. It would be great to compare approaches to things and see if we can't share and improve both in the process. The shortcodes feature impacts performance quite a bit as it's all runtime inspection, but I felt it was an essential feature. Even with it it's still fast enough that it still builds the entire site in what feels like realtime.
  - piranha 13y ago
    > It would be great to compare approaches to things and see if we can't share and improve both in the process. Indeed. Do you track dependencies to not re-render things which were not changed? > The shortcodes feature impacts performance quite a bit as it's all runtime inspection Ha-ha, in gostatic you have this `inner-template` processor, which parses your page as go template and then renders it. Naturally, it slows down rendering a bit, but still it renders my site from scratch in 0.5s (~250 pages with some inner-templates, heh).
asdf3 13y ago
This looks great, nice work! A few things I'd recommend for the future: - Theme plugins; text based as input to Hugo, not golang packages that would have to be compiled. - Editor integration so others can make a WordPress-style site editor. Just conventions about layout, I think?
- spf13 13y ago
  Great ideas. For the theme plugins, could you expand a bit on what you mean or how this would work?
  - asdf3 13y ago
    Themes should be a collection of template/css/whatever files that can be unzipped to the right location and used by Hugo. That would need standards for the file types and directory structure, config settings for which themes to use, or which parts of the theme to use. I was thinking about a WordPress replacement in Golang. WordPress themes can be zipped and shared as a bundle, which has made a large variety of themes freely available.
    - spf13 13y ago
      This is already the case. The source directory has this structure. /layouts is all the templates, /static is all the css & javascript. Just don't include a content directory and it would work just like a wordpress theme.
fosap 13y ago
So this depends on git, bzr and hg? Why?
- kinofcain 13y ago
  Only if you're building from the source which is stored in a git repo and uses dependencies from projects stored in bzr and hg repos.
jimktrains2 13y ago
Just a plug for a similar tool I wrote in python. I feel it's a bit more lightweight than Hugo. https://github.com/jimktrains/gus https://github.com/jimktrains/gus
- dkuntz2 13y ago
  More lightweight in what way? I wrote something similar myself, also in python, and put it all in one file, organized logically, with extra tools for making management easier. I'm not sure I really see how this is "more lightweight" compared to something else... For reference, it's located at https://github.com/dkuntz2/essays/blob/master/pavement.py https://github.com/dkuntz2/essays/blob/master/pavement.py.
  - jimktrains2 13y ago
    More light-weight as it doesn't have dependencies on Git, Hg, and Bzr.
    - dchest 13y ago
      These deps are only for installing from source (due to third-party packages using different SCMs).
      - jimktrains2 13y ago
        Makes sense. I was trying to figure out what he was doing with so many in his own code.
    - vanderZwan 13y ago
      But that's just the version control used by the owners of various Go packages this Go package depends on - it has nothing to do with the code itself?
      - jimktrains2 13y ago
        Makes sense. I was trying to figure out what he was doing with so many in his own code.
benburleson 13y ago
Why in the world is there a static screenshot of the hugo website, with a button labeled "Get Started", on the hugo website?
- jmah 13y ago
  'cause, y'know, the more static the better.
agentultra 13y ago
I like the idea of a static binary with no dependencies. It would be nice if my static blog generator fit in with my usual unix toolset. So good job. Just one nitpick on the marketing copy: why does it matter what it's written in? As a user it could be written in assembler for all I care. As long as it works as advertised on the tin and it's what I'm looking for, who cares if it's written in Go? Anyway, I'm looking forward to checking it out and seeing if it'll fit my use case.
- hannibalhorn 13y ago
  I'm really not sure Go is a plus in this category of application, anyway. With jekyll and it's ilk, part of the allure is that if I need to do something it doesn't support out of the box, I can just embed some code right there along with the site sources, and it'll be executed when building the site. With Go, the second you step outside the box, you'd have to recompile the site compiler first. I've had so many experiences in the Java world with having to get a whole development environment and build working just to change one little piece of text, that I really think interpreted languages are a plus here.
  - MetaCosm 13y ago
    Don't hold Java against Go :). It is all a matter of perspective I guess. Go requires 2 environmental (GOROOT, GOPATH) variables and you are ready to Go (zing). go run foo plus near instant compile times makes it feel extraordinarily script-y for small stuff. Hugo adds some external dependencies which can be fetched with `go get` (fsnotify, fsync, pflag, hugolib). One command deps are filled and you still have all the Go goodness. Jekyll requires (or generally expects) gem and requires at runtime (classifier, colorator, commander, directory_watcher, kramdown, liquid, maruku, pygments, redcarpet, safe_yaml) and for development (activesupport, cucumber, launchy, rake, rdiscount, rdoc, RedCloth, redgreen, rr, shoulda, simplecov, simplecov-gem-adapter) So, it all depends on what you value.
  - drivebyacct2 13y ago
    What? To run this you need Go, on any system (and you can cross compile it). To run an interpreted script, you need the interpreter on the destination system. From your example, it makes no sense how an interp'd language is any better.
joeblau 13y ago
This is awesome. I've been looking more and more into these types of generators for creating an OSS portal directory for Web, Mobile, Desktop, and Servers; Essentially a Kippt. Also thanks to everyone posting their projects.
- stevekemp 13y ago
  I've got a mini-review, stalled, of some of the options: https://github.com/skx/static-site-generators https://github.com/skx/static-site-generators
trebor 13y ago
This'd work pretty well with git hooks. Pretty sure you could configure a server so that if you pushed to a repository on it it'd recompile the website. That'd be pretty handy.
jaredhanson 13y ago
Nice work! Here's my Node.js-based static site generator, for interested users or devs who want to borrow ideas: https://github.com/jaredhanson/kerouac https://github.com/jaredhanson/kerouac
phaedryx 13y ago
git, mercurial, and bazaar? Those dependencies give me pause.
- gyepi 13y ago
  Those dependencies exist in order for "go get" to be able to download source dependencies that are stored in those kinds of repositories. You don't have to install them. "go get" would complain about if it encountered a dependency that required one of them, but you could install the dependency manually if you wanted to. It's, of course, less convenient.
- Ziomislaw 13y ago
  Since `go get` (official way to install go libraries) just calls the proper executable to fetch source and compiles the library, that only shows what VCS its libraries use.
trit 13y ago
Looks like the contribution guide link on http://hugo.spf13.com/doc/installing http://hugo.spf13.com/doc/installing is pointing to the wrong place (http://doc/contributing http://doc/contributing)
- spf13 13y ago
  Thanks. Fixed.
jff 13y ago
I took a quick look at your main.go file and have a suggestion. I strongly recommend against using external dependencies (e.g. bitbucket.org/howeyc/fsnotify) for something important. It's fine for development, but if "howeyc" decides he's sick of bitbucket and deletes his account, you're now screwed. If you want to use "go get" to install Hugo, make forks of the external dependencies. bitbucket.org/spf13/fsnotify and what not. You can then keep those updated at your own pace, rather than waking up to see that someone has changed their API and your code no longer compiles. Remember the game "Haunts"? IIRC this was one of their problems--they failed to manage dependencies appropriately and got into major hell. Many C and C++ programs ship source to external libraries along with their own source for this exact reason. We've taken to doing the same. Here's what Brian Fitzpatrick has to say about "go get": "Go get is nice, for you know, playing around, but if you're doing something serious and you're going to deploy binaries to production, your deploy to production script should not involve fetching some random dude's stuff on Github" We have taken to making a go "workspace" in our repos, with a bash script at the top level and a src/ directory containing all the libraries and such we've written. The bash script sets GOPATH and compiles everything in src/. It's quick and you avoid dependency hell.
- spf13 13y ago
  Great idea. That will make a lot of things easier. A lot of people struggle with obtaining the right dependencies as many people don't already have mercurial and bazaar.
  - jff 13y ago
    It puts a bit more work on you, since you have to track the dependencies, but it'll pay off the first time somebody decides to check in a radical API overhaul; you'll be able to update your code on your own schedule, not in a panicked rush because bug reports are flooding in. It also makes things easier if you decide to modify the libraries, or if the author abandons his code and someone else becomes the "canonical" source. Your code will just import "fsnotify", and you can put whatever source you prefer in $GOPATH/src/fsnotify/
- irahul 13y ago
miroslec 13y ago
I've seen this a few days ago, and I've started building a Yeoman generator for it. It's at https://github.com/celsomiranda/generator-hugo https://github.com/celsomiranda/generator-hugo There's not much done yet, but all contributions/ideas are welcome.
StavrosK 13y ago
What's the advantage of something like Jekyll over Hugo? I'm thinking of using the latter, it looks nice.

99 points by spf13 13y ago

vanderZwan 13y ago

Dammit, already taken: http://hugo.neocities.org/ http://hugo.neocities.org/ Would have been such a nice fit.

deleted 13y ago
[deleted]

piranha 13y ago

Well, here is mine: https://github.com/piranha/gostatic https://github.com/piranha/gostatic Unfortunately it has no pretty documentation, only README on Github. On the other hand, Hugo seems to have a bit more hardcoded configuration, while gostatic was written with 'whatever you want' idea in mind and is (maybe, I just skimmed though Hugo docs) a bit more tech-savvy people oriented. Anyway, it would be interesting to compare performance. :)

spf13 13y ago
I hadn't seen yours before. It looks good as well. I'd agree that Hugo is more opinionated (but not as opinionated as jekyll) and aimed at a broader audience. It would be great to compare approaches to things and see if we can't share and improve both in the process. The shortcodes feature impacts performance quite a bit as it's all runtime inspection, but I felt it was an essential feature. Even with it it's still fast enough that it still builds the entire site in what feels like realtime.
- piranha 13y ago
  > It would be great to compare approaches to things and see if we can't share and improve both in the process. Indeed. Do you track dependencies to not re-render things which were not changed? > The shortcodes feature impacts performance quite a bit as it's all runtime inspection Ha-ha, in gostatic you have this `inner-template` processor, which parses your page as go template and then renders it. Naturally, it slows down rendering a bit, but still it renders my site from scratch in 0.5s (~250 pages with some inner-templates, heh).

asdf3 13y ago

This looks great, nice work! A few things I'd recommend for the future: - Theme plugins; text based as input to Hugo, not golang packages that would have to be compiled. - Editor integration so others can make a WordPress-style site editor. Just conventions about layout, I think?

spf13 13y ago
Great ideas. For the theme plugins, could you expand a bit on what you mean or how this would work?
- asdf3 13y ago
  Themes should be a collection of template/css/whatever files that can be unzipped to the right location and used by Hugo. That would need standards for the file types and directory structure, config settings for which themes to use, or which parts of the theme to use. I was thinking about a WordPress replacement in Golang. WordPress themes can be zipped and shared as a bundle, which has made a large variety of themes freely available.
  - spf13 13y ago
    This is already the case. The source directory has this structure. /layouts is all the templates, /static is all the css & javascript. Just don't include a content directory and it would work just like a wordpress theme.

fosap 13y ago

So this depends on git, bzr and hg? Why?

kinofcain 13y ago
Only if you're building from the source which is stored in a git repo and uses dependencies from projects stored in bzr and hg repos.

jimktrains2 13y ago

Just a plug for a similar tool I wrote in python. I feel it's a bit more lightweight than Hugo. https://github.com/jimktrains/gus https://github.com/jimktrains/gus

dkuntz2 13y ago
More lightweight in what way? I wrote something similar myself, also in python, and put it all in one file, organized logically, with extra tools for making management easier. I'm not sure I really see how this is "more lightweight" compared to something else... For reference, it's located at https://github.com/dkuntz2/essays/blob/master/pavement.py https://github.com/dkuntz2/essays/blob/master/pavement.py.
- jimktrains2 13y ago
  More light-weight as it doesn't have dependencies on Git, Hg, and Bzr.
  - dchest 13y ago
    These deps are only for installing from source (due to third-party packages using different SCMs).
    - jimktrains2 13y ago
      Makes sense. I was trying to figure out what he was doing with so many in his own code.
  - vanderZwan 13y ago
    But that's just the version control used by the owners of various Go packages this Go package depends on - it has nothing to do with the code itself?
    - jimktrains2 13y ago
      Makes sense. I was trying to figure out what he was doing with so many in his own code.

benburleson 13y ago

Why in the world is there a static screenshot of the hugo website, with a button labeled "Get Started", on the hugo website?

jmah 13y ago
'cause, y'know, the more static the better.

agentultra 13y ago

I like the idea of a static binary with no dependencies. It would be nice if my static blog generator fit in with my usual unix toolset. So good job. Just one nitpick on the marketing copy: why does it matter what it's written in? As a user it could be written in assembler for all I care. As long as it works as advertised on the tin and it's what I'm looking for, who cares if it's written in Go? Anyway, I'm looking forward to checking it out and seeing if it'll fit my use case.

hannibalhorn 13y ago
I'm really not sure Go is a plus in this category of application, anyway. With jekyll and it's ilk, part of the allure is that if I need to do something it doesn't support out of the box, I can just embed some code right there along with the site sources, and it'll be executed when building the site. With Go, the second you step outside the box, you'd have to recompile the site compiler first. I've had so many experiences in the Java world with having to get a whole development environment and build working just to change one little piece of text, that I really think interpreted languages are a plus here.
- MetaCosm 13y ago
  Don't hold Java against Go :). It is all a matter of perspective I guess. Go requires 2 environmental (GOROOT, GOPATH) variables and you are ready to Go (zing). go run foo plus near instant compile times makes it feel extraordinarily script-y for small stuff. Hugo adds some external dependencies which can be fetched with `go get` (fsnotify, fsync, pflag, hugolib). One command deps are filled and you still have all the Go goodness. Jekyll requires (or generally expects) gem and requires at runtime (classifier, colorator, commander, directory_watcher, kramdown, liquid, maruku, pygments, redcarpet, safe_yaml) and for development (activesupport, cucumber, launchy, rake, rdiscount, rdoc, RedCloth, redgreen, rr, shoulda, simplecov, simplecov-gem-adapter) So, it all depends on what you value.
- drivebyacct2 13y ago
  What? To run this you need Go, on any system (and you can cross compile it). To run an interpreted script, you need the interpreter on the destination system. From your example, it makes no sense how an interp'd language is any better.

joeblau 13y ago

This is awesome. I've been looking more and more into these types of generators for creating an OSS portal directory for Web, Mobile, Desktop, and Servers; Essentially a Kippt. Also thanks to everyone posting their projects.

stevekemp 13y ago
I've got a mini-review, stalled, of some of the options: https://github.com/skx/static-site-generators https://github.com/skx/static-site-generators

trebor 13y ago

This'd work pretty well with git hooks. Pretty sure you could configure a server so that if you pushed to a repository on it it'd recompile the website. That'd be pretty handy.

jaredhanson 13y ago

Nice work! Here's my Node.js-based static site generator, for interested users or devs who want to borrow ideas: https://github.com/jaredhanson/kerouac https://github.com/jaredhanson/kerouac

phaedryx 13y ago

git, mercurial, and bazaar? Those dependencies give me pause.

gyepi 13y ago
Those dependencies exist in order for "go get" to be able to download source dependencies that are stored in those kinds of repositories. You don't have to install them. "go get" would complain about if it encountered a dependency that required one of them, but you could install the dependency manually if you wanted to. It's, of course, less convenient.
Ziomislaw 13y ago
Since `go get` (official way to install go libraries) just calls the proper executable to fetch source and compiles the library, that only shows what VCS its libraries use.

trit 13y ago

Looks like the contribution guide link on http://hugo.spf13.com/doc/installing http://hugo.spf13.com/doc/installing is pointing to the wrong place (http://doc/contributing http://doc/contributing)

spf13 13y ago
Thanks. Fixed.

jff 13y ago

I took a quick look at your main.go file and have a suggestion. I strongly recommend against using external dependencies (e.g. bitbucket.org/howeyc/fsnotify) for something important. It's fine for development, but if "howeyc" decides he's sick of bitbucket and deletes his account, you're now screwed. If you want to use "go get" to install Hugo, make forks of the external dependencies. bitbucket.org/spf13/fsnotify and what not. You can then keep those updated at your own pace, rather than waking up to see that someone has changed their API and your code no longer compiles. Remember the game "Haunts"? IIRC this was one of their problems--they failed to manage dependencies appropriately and got into major hell. Many C and C++ programs ship source to external libraries along with their own source for this exact reason. We've taken to doing the same. Here's what Brian Fitzpatrick has to say about "go get": "Go get is nice, for you know, playing around, but if you're doing something serious and you're going to deploy binaries to production, your deploy to production script should not involve fetching some random dude's stuff on Github" We have taken to making a go "workspace" in our repos, with a bash script at the top level and a src/ directory containing all the libraries and such we've written. The bash script sets GOPATH and compiles everything in src/. It's quick and you avoid dependency hell.

spf13 13y ago
Great idea. That will make a lot of things easier. A lot of people struggle with obtaining the right dependencies as many people don't already have mercurial and bazaar.
- jff 13y ago
  It puts a bit more work on you, since you have to track the dependencies, but it'll pay off the first time somebody decides to check in a radical API overhaul; you'll be able to update your code on your own schedule, not in a panicked rush because bug reports are flooding in. It also makes things easier if you decide to modify the libraries, or if the author abandons his code and someone else becomes the "canonical" source. Your code will just import "fsnotify", and you can put whatever source you prefer in $GOPATH/src/fsnotify/
irahul 13y ago

miroslec 13y ago

I've seen this a few days ago, and I've started building a Yeoman generator for it. It's at https://github.com/celsomiranda/generator-hugo https://github.com/celsomiranda/generator-hugo There's not much done yet, but all contributions/ideas are welcome.

StavrosK 13y ago

What's the advantage of something like Jekyll over Hugo? I'm thinking of using the latter, it looks nice.