Hugo: A fast and modern static website engine
gohugo.io
gohugo.io
I currently use it in place of Jekyll on github. I fought jekyll enough trying to get it to do what I wanted. Now I don't need to worry about it.
Another awesome feature: Since this is mostly used for personal sites and a lot of those are portfolio + blogs you have multiple "content type"s made by different folders. So you can show all your posts easily by iterating over the posts and then show all your projects by doing the same. They each can have separate default templates.
Odd. I found the exact same opposite. Granted, I have been using Jekyll for some time now and only tried Hugo for one afternoon. But I found Hugo very opinionated in how the site should be structured and it felt more like working with a CMS than with a static site.
I do use Jekyll, but given that a site will live for a few years at least, babysitting a ruby app isn't something I look forward to. Maybe my server has a different ruby version from my desktop, maybe some ruby gems are installed by my distribution and some others I have to install manually via gem leading to an inconsistent system state, every now and then something breaks, some functionality is provided by a gem I have to install manually and oops, I forgot to ssh to my server and install it there too. Oh, some gems can't be build because my server is hardened. Maybe jekyll got a new version and this leads to new ruby adventures.
Hugo has some other niceties too, like a built-in server with live reload and some clever link translating while testing on localhost.
Actually, you will be missing things like the meta tags for an image preview when sharing the post on facebook and other sites. This still needs to be added.
But docker also has its own complexities. A user that can run docker, is almost as good as a user with sudo rights. Would you give your CI system root access on your server? There are of course workarounds, like permit the CI system to run only the jekyll image by adjusting the sudoers file but, at some point you have to think about the scope of configuration needed for deploying your site.
Also docker on hardened servers can be challenging, for example I had to disable most of grsecurity's chroot protections to have docker run.
Having a single binary that does that is easier to maintain than a script plus a stack of ever-changing dependencies.
I initially thought the comment was just about dependency hell, but now upon re-reading I find myself wondering what sort of (static site) setup requires both server and dev machine to share dependency state.
Maybe in the case of off-line testing before a push to remote?
Thanks for clarifying for me.
Deployment via CI is important, because you may don't want all your devs to have ssh/ftp credentials to the server, or maybe you want to be able to work from many computers, yet prefer to keep your server ssh keys in only one.
Another issue is that multiple developers can use different operating systems. To be honest I have no idea how to setup jekyll on OS X or Windows. For hugo I just say to my devs “download and run this file”.
If I had jekyll set up on my home environment, I could avoid that - but if the environment was different from github's, then I'd only be able to avoid it most of the time.
- Jekyll is a Ruby thing and requires you to have pretty much all the Ruby stack, including some kind of version manager like RVM. - Hugo is a binary that you can download and stick in ~/bin/. - Jekyll comes with Sass; Hugo comes with LiveReload. - You can extend Jekyll in Ruby. I wrote a thingy for Jekyll to generate breadcrumbs and color them based on a SHA hash of the page title; I don't think I could do this in Hugo without adding this sort of functionality to it myself and possibly submitting it upstream.
If I gave up my beloved auto-colorized breadcrumbs and moved to Hugo I'd still have to find a way to get Sass to execute on every Hugo rebuild, and there's still all the things I have Gulp do for production builds (autoprefix my CSS and minify the HTML). Seems like all programs in this space helpfully offer to be file-monitoring task runners, but I'd rather not have too many for what I think are simple sites.
In any case I'd think the drawback to this is the manual updating everytime, although overwriting a single file with curl/wget is probably not much more laborious than updating gems. And less likely to break. And wouldn't have dependency problems during the update.
.. you win this round rocky1138, but don't think this is over!
I've now moved it into Lambda, so to post a new page to my blog, I drop the markdown file in an S3 bucket, and literally a few seconds later my blog is updated, Cloudfront and all.
I couldn't get to CloudFormation template deploy working, so set it all up by hand, using the scripts in that repo as a base.
Once you figure out how it works, it becomes easy to start adding other commends to run (for example, I added some lines to invalidate CloudFront when I uploaded a blog post).
If I get a change over the next week or so I'll update a repo with the scripts I use, but as I said it's based on the above anyway.
But I'm also a heavy Hugo user.
For me speed is very important. And with Hugo's great live reload, the editing of content and styles while getting instant feedback in the browser, it doesn't get much better than that.
Hugo 0.17 was released two days ago with native multilingual support. Important for some bloggers, but a pretty huge thing for documentation sites.
Thanks, didn't know that, I might take another look at it then.
I mostly did it because it's faster and sometimes I like to waste time microoptimizing my website, but I don't there's any really good reason to switch your static site generator if you're happy.
I haven't used Jekyll, but I know of a very vibrant community that exists around it. I didn't go with it as I also read about the challenge of installing it on Windows. Although I prefer other OS's for myself, I feel that having Window support as well tends to result in fewer surprise down the road.
EDIT: Some grammar stuff.
I keep seeing this question when a new technology pops up when in a crowded field there are already usual suspects out there. You shouldn't switch if all your problems are solved. Why would you?
My rule of thumb is that new technologies are for fresh projects to evaluate whether they are good fit or not. I haven't used any static site generators before so I'm open to this but if I had already invested in an ecosystem I wouldn't give it up for a similar feature set unless it's massively better.
1. Speed. Hugo generates my site in seconds instead of minutes.
2. Less dependency issues with Ruby.
I plan to clean up and package the code into a theme soon. In the meantime you can see it at https://github.com/hypertexthero/sgg
That said, I typically grab from site templates and don't do a lot of css/js manipulation myself. Though, if I did, I'd just set-up Grunt or Gulp to handle automatic regeneration of the final asset files.
For those asking why should you switch? Well, exactly, why should you? If you are happy with your current toolset and are productive using it, isn't it all about the final product anyway? Who cares what you use. But if you aren't happy with your toolset, or are just keeping an eye out for something that might be better ...
Hugo is known most for its speed. If you have a site with many, many pages that needs to be built quickly, strongly consider Hugo. It really is super fast. I'm actually considering building out a very large sample site with various engines to demonstrate just how fast it is. I'll try to find this post on Hacker News again and post if I ever get around to it.
Layout of content is extremely nice in Hugo. Basically, you just organize everything in directories how you want it to be rendered in the end. This can be overridden if necessary.
Documentation is also really nice. I'm actually about to build another client site and considered using Jekyll (you know, just to see), but found the documentation lacking compared to Hugo. It also seems to needlessly complicate things, but that's probably just personal opinion based on prior experience with Hugo.
There are a few downsides obviously. You get what you get, unless you want to add functionality and recompile. But now you have to maintain your own version.
As parent5446 mentioned, variables can be a bit confusing. They are not as idiot proof as I'd like them to be.
The lawyer site was done with the Elevation theme from Templated.co. Less manipulation here, other than a few changes of tags for SEO purposes. No CSS framework (that I know of anyway), skel.js and jQuery.
A good way to a lot of different ways of how people are using Hugo is with the site showcase.
That would be fantastic. Do you have any shortlist of engines you are going to test?
Also, I have a question about the two website you've built. Did you also write the copy (content) yourself or was it sourced from the client/a third-party?
There are initiatives writing some nice clients on top of static site generators such as Hugo and Jekyll, but in my head you then lose out some of the most valuable features of Hugo, speed and simplicity.
Full disclosure: I work for Contentful.
Further thoughts on this: https://poststatus.com/static-site-generators-versus-wordpre...
My favorite tool for static websites is Middleman (https://middlemanapp.com/), but competition is always good.
2. Modern
I feel most comfortable with pelican but with huge sites it gets kind of slow.
Everyone has different needs and tastes so no tool works for everyone. Here's how I see Hugo's strengths and weaknesses. I'd love to know what other people see are Hugo's strengths and weaknesses.
Hugo's key differentiators: 1. Ease of install 2. Speed (critical for large sites) 3. Integrated live-reload while editing in near realtime 4. Multilingual capabilities 5. Flexible 6. Very strong community 7. Very good & comprehensive documentation (but not perfect...yet)
Hugo struggles with: 1. Not integrated with Github like Jekyll (though webhooks solve this to a large degree) 2. No plugin support 3. Media & Asset processing not tightly integrated
There are many solutions that work around Hugo's limitations, some which are quite elegant, but at the end of the day they are workarounds and require external tooling.
We would love to address these weaknesses in upcoming releases as best we can. If you are interested in helping we would love to have help.
Hugo predates those two. It got its first tagged release almost a year before Metalsmith and two years before Lektor.
Another is that it's a single file to deal with. This may be different when you get into making your own themes, but to get going you just need to download the single file for your platform.
That doesn't make the benchmark totally uninteresting, though, because dealing with 5000 posts in 5 to 7s is still good, and would be what you'd get from several rendering iterations, which you'd get for subsequent edits of your text, or tweaks of your templates.
The point I'm trying to make is that he should not care about showing more than one measurement.
I found middleman to be the most powerful static site generator.
I had to try to hack add ons like jekll paginate.
Hugo actually had all the features I wanted but It was something to do with the locations of templates for custom collections were in a very opinionated yet weird place and the docs werent super clear about how it worked? And theres literally only a handful of tutorials.
Theres a lot of good about Hugo though and Im not denigrating it all.
Middleman was just perfect on every level. Elegant, customizable, feature rich, with great docs.
Its also Ruby so its like an evolved Jekyll pokemon.
But then again all this is just my opinion. :)
Hugo's speed is overrated (and overstated). Anything with caching (like Pelican) makes this somewhat of a non-issue IMO. Incidentally, the longest part of generation for me is thumbnails and other asset bundling, which is essentially imagemagick.
Having said that, Hugo does many things right and is pretty fully featured, so it's hard not to recommend. It would be nice if all static site generators used the same format (front matter?) so switching engines could be more seamless.
It's great for a simple static site, but without a way to extend the template engine easily, there was no way to do what we wanted (which was to style a yaml file of service metadata into a swagger like UI).
For me it is better because of simplicity and speed. I use it to power a 400 page blog (https://shapeshed.com/) with this source code (https://github.com/shapeshed/shapeshed.com).
I used Jekyll in a small organisation and it meant everyone needed a working Ruby environment This caused much pain across platforms. Hugo ships a single binary for multiple platforms so setup is far simpler. It is also amazingly fast and there have been major performance improvements in 0.17 too (https://gohugo.io/meta/release-notes/).
I love it!
One of the problems is that it's not easy to integrate Hugo into any other build process. For better or worse, many website build tools right now are in JavaScript (npm, bower, gulp, grunt, yo, etc.). And on the flip side, Hugo does not do any static resource processing. So for our site, we needed to have Grunt tasks fetch third-party libraries, compile the JS and CSS, perform lint checks, and finally put files into the correct location so that Hugo could then be called to build the final site. Now, to be fair, Jekyll core does not do any of this for you either, but at least there are plugins in Jekyll [0], and integration of custom build scripts becomes a bit smoother.
This brings me to my second pain, which is shortcodes [1]. It is the closest Hugo has to plugins. Hugo completely disallows writing raw HTML in Markdown content (the cited reason is it "is in complete opposition to the intent of using a bare-bones format for our content and utilizing templates to apply styling for display"). It makes sense, and I'd use a system that separates raw content from more complicated code. But when you start needing to put dynamic content in your site, shortcodes in Hugo specifically are extremely unflexible. You're stuck using the Go template library that underlies Hugo, which gives you very limited information about the page being rendered.
Local variables, for example, are not scoped the way you think they are, and you are stuck with a "scratchpad" hack that Hugo put in [2]. To see this in action, here is code I had to write to make a shortcode for responsive images [3]. The entire process involved starting with a JSON file containing the shared configuration, having Grunt read this config to generate the images, and then using the code in [3] to also read from that file and find where the images would be. This is all without syntax highlighting or any useful debugging tools.
There are also just some times you really need HTML in your Markdown, and it doesn't make sense to use a shortcode. For example, a web page that contains very specific formatting that cannot be expressed in Markdown, but is also specific enough to that page to not be separated from the page's content.
All in all, we switched to Hugo for a reason: it had many features that Jekyll was missing at the time (although many it has since added). We wanted to express our website in a well-structured format that also allowed Markdown so not-especially-tech-savvy people could edit content. In the end, we got it working (here's the site, a good example of how a Hugo site can come out pretty great IMO [4]), but it caused a whole lot of pain and misery for me.
[0] https://jekyllrb.com/docs/plugins/ [1] https://gohugo.io/extras/shortcodes/ [2] https://discuss.gohugo.io/t/counter-variables-and-template-s... [3] http://pastebin.com/ZjiWpDHc [4] https://www.castlepointanime.com/
I came over from lektor to hugo. As much as I liked lektor's UI (via local website), hugo's binary is far better for me since I'm constantly jumping to different machines (windows, linux, OS X), and didn't want the hassle of set up on each.
That being said, the one thing that is annoying with hugo - and I DID see this with lektor as well though not as annoying as hugo - was wiring up your first template. Ugh, configuring templates - or perhaps more specifically variables - is a big time sink. Other than that, hugo is my generator of choice.
And as parent5446 said, the shortcodes don't give you enough information in some cases.
I also think that people who aren't very technical will have a hard time getting started with the Go templating language, whereas Jekyll is dead obvious (super loose scoping, it looks like any other scripting language, etc.)
Hugo was a breath of fresh air:
- Easy to install (auto-installs all the dependent go packages without a hitch, and results in a single static binary!)
- Easy to set up a web page (hardly took 10 minutes)
Having the basic web site building going, I can now tinker as I like with the layouts, config.toml, etc. Hugo has allowed me to focus more on my web site content and design than burning time figuring out how to successfully install (and keep upgraded) the web site building. (All I need to do to update hugo to the latest and greatest is: "go get -u -v github.com/spf13/hugo").
https://blog.docker.com/2016/09/announcing-new-docs-repo-git...
In the blog article above, they mentioned a problem they faced.
> The docs were built around Hugo, which is not natively supported by GitHub, and took minutes to build, and even longer for us to deploy.
I've been using Middleman for static site for a couple of years. I'm thinking about moving to Hugo because I read HN comments Hugo is much faster than other alternatives. But reading the official Docker blog, I'm thinking twice.
Could anyone tell me the reason why Docker blog took too much time to build with Hugo that is supposed to build really fast?
> the reason why Docker blog took too much time to build
Not the blog, but documentation. And it takes so much time because it's just so huge. Just by itself it would be pretty big, but consider that they maintain a clone for each release version. You end up with lots of documents very fast.
What I'm not sure about is why it would have to be completely rebuilt every time since the build results would have to be committed. Maybe they had two repositories? Or Hugo can't do "incremental" builds well?
From my reading of their blog post I see that their primary motivation for the change was first to consolidate all of their documentation into a single repo, instead of spread across all of their various projects. As they have grown as an organization and now have a large number of projects this approach has a lot of strengths and makes a lot of sense. Any SSG could work in this new formation, but the change gave them an opportunity to make a change. Additionally Github provides a lot of Jekyll features out of the box that help with managing these documentation sites.
I believe it is not a question of performance between Hugo and Jekyll, but a question of Docker's specific workflow. As Github already runs Jekyll server side all the contributors need to do is upload the source file and then Github does the rest. In contrast, Hugo based docs would have to be built locally and then uploaded as completed html. There are easy ways to set up services through github hooks that do the exact same thing as Jekyll already does but that requires additional setting up.
Since Github is doing all the work it is easier on the contributors since all they need to do is `git push`. This also enables people to edit right in the github edit screen and not bother with setting up anything client side. The total time to process the site is likely much longer on Jekyll but the time that their contributors spend is much less as they aren't building the site locally.
Hugo falls short when it comes to custom needs, like EXIF handling, or intermediate image downsizing for responsive images, because adding features to Hugo is painful.
The plugin system let's you do nearly anything you can think of,and if not the devs are will consider updates to make it possible
I'm familiar with Pelican. Apart from writing plugins (with excellent signals to hook into), you can replace the main class with a custom class and get basically any behaviour you want.
[0] https://jekyllrb.com/docs/plugins/ [1] http://docs.getpelican.com/en/3.6.3/plugins.html
I do like Hugo because of the speed and portability.
I was using this instead of Jekyll for a hardly updated website and I can't get it running on Arch linux (without putting too much effort into it). The whole system looks pretty dated and dead too (I think the upstream URL doesn't even work any more).
I would be really happy to get a "set and forget" solution, so I can update the site 3 times in a year and don't have to worry about the system.
Is Hugo stable enough for something like that ? Is the Jekyll Docker image the better solution for this ?
The main reasons I like hugo:
- The single binary (which others have mentioned)
- The theme support (Somehow, Hugo themes are well designed as opposed to Pelican themes which seem more thrown together)
- The folder structuring is very intuitive
All in all would definitely recommend
* https://news.ycombinator.com/item?id=10646508
* https://news.ycombinator.com/item?id=10627585
Strangely I can't find any posted story for the 0.16 release...
Started building sites ... Go initialization: 5.722103073s (5.722526117s) 2.66 MB 22083 Allocs
The rest of the steps take 115ms. What is happening in go init, and why does it take so long?
Many of the performance optimizations have tradeoffs and while they increase performance for the majority of cases, some cases will experience slight degradation.
This is also a surprisingly long time for initialization. My site with a few hundred pages on a rather old mac (with an SSD) has
Go initialization: 48.00164ms (48.842363ms) 2.14 MB 18299 Allocs
Do you have your site source available publicly so we can do more testing and benchmarking with it? We'd love to understand the places where it's not improving so we can address them further.
I wonder how fast Hugo would be if it was written in Pascal instead.
The next weekend you will already have forgotten how to work it and you think "fuck it" and either install Jekyll (which is also a piece of shit, but it is a piece of shit that has a bigger community) or you think "screw this" and sign up for some website generation service your slightly odd uncle uses.
Wake me up when someone makes a website generator for people who really aren't interested in website generators.
After using Drupal and Wordpress for years they're a total breath of fresh air.
I can put together a site in a fraction of the time it would normally take, host it for free, and through services like Snipcart, Typeform and Forestry.io, add some surprisingly sophisticated functionality.
For what they do, Hugo and Jekyll are excellent.
Y'know, that one your odd uncle is using.
For instance so someone can use it to build a website generation service. (Yeah, you kinda do have to solve the basic problem of generating the HTML anyway, so one might as well focus on doing the core part of it well)
I'm not saying it is easy. In fact, it is hard because people tend to get too familiar with their own mess. Or they think it is easy.
(And no, that wasn't angst. That was realism conveyed in a honest manner)
Been thinking about doing exactly that as a side project.
Main features:
* Free as in Beer & Source
* Available as Chrome Extension and Desktop (Electron) App
* You add posts / pages using a UI
* Select themes like you do in Wordpress
* Click to push to GitHub pages, Amazon etc.
* Save as JSON for portability and backup
* No Command Line. No dependencies.
Focus on getting the basics right.
The itch I am scratching here is for:
1. Someone who knows the benefits of a self-hosted static site over say wordpress.com/.org. So probably some technical.
2. But doesn't want to learn another command line app, a new templating system etc. Just wants to write stuff and publish it in an intuitive way. They don't want to shave that Yak to write their blog. Hell they are so damn lazy they don't want to download and install anything! (hence a chrome app)
I currently solve this using Github pages, letting it generate the site for me so no local install. But that feels a bit locked in.
Making something a website generator isn't easy. Not least because people who design and implement these things seem to love fiddling around with website generator tools. Which isn't necessarily what users like.