Hugo v0.15 releasedL Higher performance, Jekyll import, template improvements
github.comHighly recommended, fast, simple to install (single binary), super responsive team if you find any issues and reliable. Compared to the jekyll/octopress/ruby ball-of-twine that it replaced (which would break at the most in-opportune times for no apparent reason) the speed increase is phenomenal, there is even a mode that re-generates the site on the fly on changes with a local server, it is so fast you can't move your eyes from one monitor to another while saving or the page is already updated. Of all the static site generators that I've tried it wins hands-down.
I have not used it but one of the things I was concerned about is extensibility. I am unable to find any documentation on this. Due to it being in Go, is the recommend way to programmatically extend Hugo to make modifications in the Hugo source tree and recompile?
Hugo is built is a way that virtually everything you would want to do with a static site generator is configurable without go or recompilation.
Smashing Mag had a good write up explaining this http://www.smashingmagazine.com/2015/11/static-website-gener...
I am working on porting a mostly-data site to hugo now, and it has been a nice experience.
I did find myself wanting to introduce custom logic - like custom helper funcs for the Go templates - but there is no way to do this short of modifying and rebuilding hugo.
Specifically I wanted to use some functions from here: https://github.com/dustin/go-humanize
In the short run, it was fine. Since most of the data is structured I could write a script to modify the input data to prepare for output without modification.
Not sure about hugo's longterm plan for this type of thing, but overall it is an awesome project and would highly recommend over every other static site generator.
I know that Go is looking to add support for loading code at runtime, so a plugin system doesn't seem out of the question once it's landed.
https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...
You can embed parameters in the front matter, then pull that data back out in the templates, but I haven't actually done this see:
https://gohugo.io/content/front-matter/
That still leaves you with the problem of populating the front matter.
What would you like to do? 1-2 concrete examples please.
I have not used it so it is a bit unfair to ask for concrete examples of what I would need that it doesn't do. But in general, something like using the GitHub API (as my user) to obtain a list of recent commits to format a certain way could be an example.
But in all honesty my question was also wondering if this had a good story around runtime Go compilation since I am building a Go project that could be construed as a "static-binary generator" for an orchestration and configuration management system.
I've implemented the getJSON Feature http://gohugo.io/extras/datadrivencontent/ and this should be what you are looking for ;-)
One thing that I'd love to be able to do with Hugo (I'd probably switch from Middleman if this was possible): dynamic proxy pages:
https://middlemanapp.com/advanced/dynamic_pages/
"Middleman has the ability to generate pages which do not have a one-to-one relationship with their template files. What this means is that you can have a single template which generates multiple files based on variables."
So I can take a JSON file with an array of data, and generate a file dynamically for each object in the array.
Last I looked, I couldn't figure out how to do this with Hugo. Is it possible now?
Are the some examples on how to implenent a statically regenerated blog in a static site?
I love Hugo and use it for my site.
Speed didn't seem like an important feature until I was refreshing my 700 pages trying to find tweak a theme change. And now with the new 30+% speed increase in the `hugo server` command, it just got a lot better.
My favorite feature is the single, no-install, no-dependencies binary than works perfectly on all OSes. This is huge for Windows users. You may get lucky with the Ruby/Bundle madness of other static site generators on Linux, but Windows support is often lagging or non-existent. With Hugo, one binary and done.
Recommend.
I agree re: speed. In my experience, speed doesn't matter until it does: I don't care about 650ms vs. 700ms, but once it passes the threshold of me alt-tabbing waiting for blog/public/ to regenerate and I lose focus, it becomes near-unbearable.
(This probably applies to all build processes, not just static site generation.)
That's the whole 'Go' community in a nutshell, speed really does matter, even for compiles. That was the one advantage Borlands' products had.
Agree, and it can be even more pronounced. I tried to move to Octopress first and it took many seconds to generate my site (forget the fact that I never got it working right on Windows). Hugo is a few hundred milliseconds. That is a big difference and matters when I'm trying to rebuild 3-4 times a minute.
> My favorite feature is the single, no-install, no-dependencies binary than works perfectly on all OSes.
Yup. Consistent on Linux and Windows is very useful for me. The python world are pretty good about cross-platform, but not as good as Go, and the ruby world has an attitude that might best be characterised as "sneering contempt."
My current personal site is on Middleman, and I cannot update it from any other laptop other than my own personal one because of Ruby and all the dependencies. Bundle install compiles some native gems, which fail for any number of reasons, and are extremely difficult to troubleshoot (I spent 2 hours to no avail before I gave up - and this was on another Macbook!). I use Hexo ( https://hexo.io/ ) of a few other sites, and it is much better cross-platform, but still has occasional issues with dependencies.
I am done with Ruby static site generators. Node.js ones are much better, but it sounds like I need to give Hugo a try also. Great work!
I switched over to Hugo for my personal blog and a side project from Pelican a couple months ago. The speed is unparalleled: anecdotally, it generates a couple thousand pages in ~400ms (which would take an order of magnitude longer in Pelican). However, dealing with ACE templates was like pulling teeth, and I was considering switching away just to save me the stress; I'm glad to see that they're working on improving the actual templating process (and that ACE apparently supports base templates now?)
ACE base template support was introduced in Hugo 0.14, but was now completed in Hugo 0.15 to also support using them in themes. It can really clean up your templates.
There are some cool improvements in the upcoming Go 1.6 that will make the regular Go templates a lot nicer to work with (Hugo 0.16, maybe?)
I'm interested to hear what folks use to kickoff Hugo for sites hosted on GitHub Pages? TravisCI, CircleCI, etc?
This considering GH pages has build-in support for Jekyll but not for other static site generators.
Give netlify a try https://www.netlify.com
It's like GitHub pages on steroids (SSL, redirects/rewrite rules, proxying, domain aliases, etc, etc...). It'll run any build tool for you (not just Jekyll) and we have built-in support for Hugo:
https://www.netlify.com/blog/2015/10/06/a-step-by-step-guide...
Disclaimer: I'm a founder :)
I like Wercker which works well on github pages, s3 and ssh. There's a good tutorial at https://gohugo.io/tutorials/automated-deployments/
I just used this technique for https://stevefrancia.com and the wercker files are at https://github.com/spf13/stevefrancia.com
I just build locally and push the results to GitHub. Master branch is the generated site, hugo branch is for the code.
I use a git hook that builds locally on commits to master (with some cleaning just in case I was testing weird things from non-master). I host on s3, but I don't think the s3 transfer vs github push is of great consequence here.
Wercker's a great option with Aerobatic & Bitbucket. Here's a blog post on how to set it all up: http://www.aerobatic.com/blog/hugo-continuous-integration-wi...
disclaimer: I work for Aerobatic
Template improvements.. The go template system is..opinionated to say the least. It's my biggest pain point in the language, and I include having to write min_int64_int type functions.
Anyway, hugo's documentation, code quality and template improvements are stellar, congrats on the release.
I would love to see support for pongo2 (which is a Django style template library). Working with template inheritance would be so much easier.
> Hugo now supports dynamic reloading of the config file when watching.
As one just starting with Hugo and still tweaking stuff, this is probably my favorite new feature.
How does Hugo compare to Harp? http://harpjs.com/
I've been enjoying Harp's ability to easily launch a web server for local development using jade + scss and compile everything to html and css before pushing to GH pages.
Any benefit of switching to Hugo?
Hugo provides many of the same features of Harp.js which is also a good project.
Hugo provides a server for local development like jade.
Hugo is a bit easier to install as it doesn't have dependencies and doesn't require an existing environment.
Hugo is noticibly faster.
The big difference between the two is that Hugo has not focused on compiling all the other assets like scss, less, coffee script, etc. While this is planned for a future release today Hugo users have experienced a lot success pairing Hugo with Gulp. You can read more in this discussion on the forum: https://discuss.gohugo.io/t/gulp-hugo-hugo-npm/1121
Unfortunately by introducing gulp it negates some of the benefits of Hugo's one binary install.
Hugo does provide some advanced features that I don't believe Harp provides including:
* Data file loading https://gohugo.io/extras/datafiles/
* Live data https://gohugo.io/extras/datadrivencontent/
* Live reload (this is a huge feature) https://gohugo.io/extras/livereload/
* Menus https://gohugo.io/extras/menus/
* Themes https://themes.gohugo.io
If you are happy with Harp and it serves your needs than there's not really a reason to switch.
The big difference is Hugo + Gulp is a workflow that works really well and has all the features that Harp provides (plus all the Hugo features). If you need a feature that only Hugo provides there really isn't a way to add that to harp.js.
I'm the author of Hugo and haven't ever used Harp so take all of this with a grain of salt.
Does Hugo do any of the more advanced build tasks, like image compression&inlining, sass/less/postcss conversion (and minification)? How does it fare wrt to adding javascript behavior to pages (e.g. React components), do I have to setup a separate build system for that stuff?
Currently hugo has not focused on this aspect of development and many people have found success combining Hugo with Gulp. There are a few projects related to this that make it pretty easy. There's a good discussion around this on the forum. https://discuss.gohugo.io/t/gulp-hugo-hugo-npm/1121
This is great. I'm working on a static hosting service to make the deployment story for static websites easier. It should be live in a few days: http://statichosting.co/