Let’s celebrate Hugo’s 5th birthday | Hacker News Reader

Let’s celebrate Hugo’s 5th birthday

gohugo.io

149 pointsrobin_reala60 comments

Hugo is nifty. It is in Golang. It is wicked fast.

But.

Like most of the static site generators out there, it is so hyper-focussed on some aspects that it stumbles or completely misses others. I believe that Hugo (and others) take Markdown in precisely their expected format, and layout, with their format of header and, with precisely the correct version of config file and template.. turn it into some really nice looking HTML. Fast.

I guess - even after 5 years they aren't attempting to call it 1.0 at least. Maybe the other things will get fixed before then.

You might even be able to take your existing Markdown stuff and convert it - but be prepared to fiddle with Markdown syntax a bit, and headers, and file layout, etc.. potentially for hours. And hours and hours. And hours and hours. Not so fast any more, is it? Hugo is not alone here.

The number of themes available is amazing! And they look fantastic! But - you're going to have to spend many more hours digging to find one that puts the blog on a separate page, instead of front and center.. because 80%+ of them are oriented towards blogs only.

Now.. a week later... new minor release time. Does the new release work with your existing config? With your existing theme?

Oops - you waited a month and missed a few minor releases.. will everything break now? How do you ensure that your theme keeps up to date with your release? Git hooks, git submodules? What fun! How.. fast? Not if you're futzing with all this stuff.

Hugo isn't alone here - Jekyll, Pelican to name two I've tried also have problems to a greater or lesser degree.

Software should be judged based on how useful it is. Hugo isn't what you or I would build, but a lot of people find it incredibly useful. Same as WordPress, where their slogan "code is poetry" makes me think "yeah, vogon poetry".

It's also reasonable to judge it by how good it could be, and by how far it misses that mark.

Reasonable, but not as effective IMO.

Do you have any experience with Org publish/export, and does it suffer from the same problems?

Hugo is by far better and more stable than org-mode exporters. Tried all, stayed with hugo, even if I don't like go that much.

Can you expand on that a bit? Can Hugo not take other formats?

I use Pelican. It supports markdown and rst out of the box. It's fairly easy to write a plugin to support another format. So I wrote one that takes in Org files (I think it just uses pandoc behind the scenes to convert to rst). Writing posts is much better now that I can author them in Org mode.

So if someone wants to author in Org mode, but not use the clunky Org exporters, consider using a static site generator that allows you to have a custom input format.

I love org-mode, but the export is a mess. It produces sloppy HTML and garbage CSS, what I want is semantic HTML5 and custom CSS. Actually, I should probably just spend the time to build what I want and contribute it back to the org project.

I actually have it customized to put some CSS in, but it is suboptimal.

    (setq org-html-doctype "html5")
    (setq org-html-head-include-default-style nil)
    (setq org-html-head
          (concat "<meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">
    <link href=\"https://cdnjs.cloudflare.com/ajax/libs/normalize/4.1.1/normalize.css\" rel=\"stylesheet\">
    <style>" (string-from-file (concat eddie/default-emacs-dir "style.css")) "</style"))
    (setq org-html-head-include-scripts nil)

Hello kqr! I didn't expect Org mode to be mentioned in this Hugo thread. So I'd like to mention my ox-hugo[1] project here. Here are few real-world examples of people using ox-hugo + Hugo: https://ox-hugo.scripter.co/doc/examples/ (while on that page, also search for "Exported from" :)).

ox-hugo basically lets each tool to do what they are best at: Org mode deals with the rich markup and Emacs/Elisp processing, and Hugo deals with the super-fast Markdown->HTML conversion.

[1] ox-hugo is an Emacs package that exports from Org mode to Markdown format that's compatible with Hugo/Blackfriday + automagically converts natural Org metadata to TOML/YAML front-matter.

Well, to be fair, the problems you've pointed out are quick fixes.

Hugo works fine out-of-the-box with markdown files that don't have any headers. You'll just be seeing some reference errors for things like Title, probably.

And moving the blog to a separate page wouldn't take hours. The homepage comes from `layouts/index.html` [0], and each type of page already has a list page ( `page_type/_index.md` ).

Not sure if it'd really take that much longer to get your head around how Hugo works versus a traditional CMS. At least with a static-site generator, if you keep it outdated (and therefore don't need to bother with any breaking changes), any unfixed vulnerabilities aren't facing the web.

[0] https://gohugo.io/templates/homepage/

Jekyll has gotten pretty fast too, especially if you enable incremental building.

I've tried Jekyll on multiple occasions and have always been put off by just how huge the tool is.

I just want to turn my markdown into pretty HTML. That's all. Jekyll feels like this giant sledgehammer that's built to hit a tiny nail... and doesn't even hit the tiny nail correctly every time.

Care to elaborate?

In my case, when I wrote a plugin for Jekyll, I felt mildly upset about all Ruby things I needed to install and to some degree understand. I felt Jekyll was too complicated and complex. — Maybe if one is used to the Ruby world already, one won't feel in that way.

> I just want to turn my markdown into pretty HTML. That's all.

If you're not looking for a static site generator, maybe Pandoc is more what you're seeking?

Not to be a wise ass, but because I'm genuinely curious: who cares how fast it is? How often are you regenerating pages? Or is it a factor because of the change-make-check-change-again cycle?

It matters if it takes more than a short while to post your stuff. Jekyll/Octopress would take 20 minutes or so to regenerate my not all that large blog, I imagine that with 1000's of pages it would be unworkably slow.

I switched from Octopress to Hugo and it couldn't have been more painless or pleasant. This was still early days for Hugo, I ran into a bug, posted a ticket and had it fixed in a few hours.

Upgrading from one version to another has been painless as well so far.

I just switched my personal site from a custom Python script that generated markup to Hugo...plus custom Python scripts.

I wanted to automate the upload process too so I made something that is somewhat but not quite rsync-like (it uses a date and size heuristic to do fast incremental updates) - and then for the site content I realized that Hugo's design was resistant to text + image bundling, favoring static data independent of markup. The documentation on making a bundle work from within Hugo was both extremely limited and actually broken on current versions.

So I just rolled another script to publish content with. All it does is pre-process the Markdown and copy files.

Still, by going this route I'm still gaining advantages over the old system. It's nice to have a system that takes care of common stuff - themes, list generation, final markup. But it's much more valuable when it's supplemented with a custom system that lets me author the content at the level of abstraction I need.

Did you read the blog post at all? It's a little bit ridiculous how many of the things you mention here were also mentioned there.

You: > I believe that Hugo (and others) take Markdown in precisely their expected format, and layout, with their format of header and, with precisely the correct version of config file and template.. turn it into some really nice looking HTML. Fast.

The post: > Currently, in addition to Hugo’s list pages, every URL must be backed by a content file (Markdown, HTML etc.). This covers most use cases, but we need a flexible way to generate pages from other data sources. Think product catalogues and similar.

You: > I guess - even after 5 years they aren't attempting to call it 1.0 at least. Maybe the other things will get fixed before then.

The post: > Hugo has stuck with the sub-zero versions to signal active development ... But we are closing in on the first major stable version.

You: > Now.. a week later... new minor release time. Does the new release work with your existing config? With your existing theme?

The post: > with a new main release every 5-6 weeks. But we take stability very seriously (breaking things add lots of support work, we don’t like that) and most site upgrades are smooth.

Words in a blog post are easy to write, the proof is in the actual use of the software. But equally, to me this post strikes a positive tone about the future of Hugo as more than just a tool that helps you ditch WordPress. A lot of that work will have already started and I'm sure they would welcome your contributions, large or small.

I used Hugo for a while, but I feel it's really held back by its templating language.

I've recently moved to Gutenberg[0], which is very nearly a clone of Hugo except for the templating language. After some benchmarks[1], I concluded that it's even faster than Hugo, and the ergonomics of using the templating language are far, far better.

[0] https://www.getgutenberg.io/

[1] https://www.codesections.com/blog/gutenberg-vs-hugo/

It is also held back by its implicit stuff, and counter-intuitive internal logic. Jekyll is infinitely more intuitive. I tried both: went from Jekyll to Hugo, and back and I'd never touch Hugo again.

I would also mention that sometimes the Go internals leak and it is also not convenient.

> but I feel it's really held back by its templating language.

That's very subjective. It's templating language is one of the reasons why I use Hugo. It reminds me very much of Lisp ({{ or $foo $bar }}).. parens replaced with double curly braces.

Now, everyone doesn't like Lisp :)

Back in the day, before WordPress sadly became dominant, I made my own static site builder with Perl and Make. Yes, feel free to point and laugh. But it was awesome. It’s nice to see static site builders like Hugo gaining momentum. With so much going on on the client these days, having a static back end is a great idea (again).

> Yes, feel free to point and laugh

Why would we do that? Text manipulation (translating from a simple markup format into HTML) is Perl's bread and butter! And make is pretty easy to set up to have new general-purpose rules (e.g. .md -> .html).

This sounds like what Movable Type was way back... i used it around the year 2000/2001, and it worked great... then the dark days of Wordpress came along, and ugh... Its only in the last year or so that i moved back to static sites, and just last week moved my site to Hugo. very happy with it so far too!

back in the day, a friend of mine also made a perl-based static site generator for her blog, and i totally made fun of her for it, because, who would want a static site?!?! and perl?? ugh.

i thought my (dynamic) blog custom-built in php was the bee's knees because i could have comments and my own admin interface. how silly i was. =) particularly with the advance of front-end development (and automatable deployment pipelines), static generation makes so much more sense now.

If Perl why not Template::Toolkit? I still use it after 15 years. What I like about it is that it gets out of your way and doesn't assume your site is a blog. It just converts template files to corresponding HTML files and that's it.

That's what I used.

"I made my own static site builder with Perl and Make"

I assumed you'd rolled your own as TT doesn't require Make.

Anytime I work on a new web project, the first question I ask is how can I make this completely static. Hugo is my first choice to make it happen. It's REALLY nice not worrying about databases / programming environments / user accounts.

Maybe this isn't the correct place to ask a question like this but how do you avoid interacting with a database or user accounts? Is it at simple as you don't have any of that in your application?

Mostly that. If you take out all of the "social" aspects of most modern websites. Then they really don't require backend databases and accounts. I've been moving back to more of a minimalist/purist approach.

Static sites are great for simplicity, but IMO we should be striving for more interaction not less. If I open a blog I want to be able to host comments and not rely on email or third party services.

Maybe we need a hybrid site generator. We could still write the content as seperate text files, but we would have the ability to integrate comment sections, user profiles etc. seemlessly.

Our posts could be parsed and recorded onto a database, for better indexing, search, analytics and reducing redundancies.

The generator would come with a web server and handle everything we throw at it. From ssl to comments to databases.

That's the future I dream of. Not full blown CMSs, but not web 1.0 either.

Sounds great, but comments are the first thing I'd prefer just disappear from the internet. I understand that is what brings users, but they are generally cess pools of assholes and spammers.

I agree. Comment sections tend to be really hard to moderate. I accept comments via email and then I manually add them to articles as part of the main text. This is a largely self-moderating system because only when a reader honesly thinks their comment is important do they bother emailing. While I always respond, I only include the comment in the article if I think it is of greater value to the community at large.

It's not ideal, but it is as close as I have come to showing someone an article and asking for their comments IRL.

That's a massive amount of work though. Is there nothing to come from all of this "machine learning" nonsense talk, putting it to actual good use automating this?

It's probably not that hard to build something like that yourself. I remember my first project on Github back when I thought web development was PHP and nothing else was something that felt like a static site generator (all my articles were hand written XML pages with markdown blocks) but would generate blog indexes etc (including its own comment section) by parsing the XML and rendering them to "components" (basically php pages that handled content and arguments and returned HTML). It also had a super simple caching bit (like most forums/blogs do anyway) so it was almost static I guess.

A lot of people are doing these things already!

The Forestry.io blog has a number of articles covering some of these topics:

* eCommerce – https://forestry.io/blog/snipcart-brings-ecommerce-static-si...

* Search – https://forestry.io/blog/search-with-algolia-in-hugo/

* Forms – https://forestry.io/blog/5-ways-to-handle-forms-on-your-stat...

* Advanced Image Handling: https://forestry.io/blog/master-image-delivery-with-cloudina...

* Building APIs – https://forestry.io/blog/build-a-json-api-with-hugo/

Regarding user profiles, the Forestry website itself is built with Hugo and has a Rails app to handle profiles.

EDIT

I know you don't want to rely on third party services, but if it's possible to handle this with third party services then surely open source alternatives could be built.

Thank you for curing my curiosity.

You can set up a good bit of those sorts of complex interactions via webhooks. For instance, here's a good tutorial on setting up a comment system[0]. It's also how the forestry.io[1] CMS works.

However, building out a user account system this way is probably theroetically doable, but definitely not practical.

[0] https://css-tricks.com/jamstack-comments/

[1] https://forestry.io/docs/welcome/

Netlify has a paid product that will work if you want to paywall some content, if that's what you're asking.[1] Not interacting with a database is sort of the point for a static website.

[1] https://discourse.gohugo.io/t/static-site-behind-login/10100

Having my Hugo blog up on GitLab, with their CI/CD pipelines hosting and building my site and on every git push, is pretty great. I am only paying for a domain name and nothing else, and not having to worry about a host going away or shutting down is also pretty nice. Even if GitLab went away tomorrow I could have my site back online in minutes.

I’ve worked on projects where Hugo was the chosen tool and I may be missing the forest for the trees but when I encountered the templating syntax I considered it a red flag. Like “this is horrendous, but these people seem to just accept it - I wonder what other painful surprises await me down the line?”.

And while it’s build-speed is impressive, I’m of the mindset that if your site is large enough that build-speed is a genuine concern, rebuilding your site every time you make a change is a bad idea, and perhaps a dynamic tool is a better fit for the job.

I also had the same feeling. I dumped Hugo in the end.

What did you use instead? @edem? (& @subpixel, were you in the position to pick sth else?) ... Aha, Jekyll, right? I now found in another comment here.

I am huge fan of Hugo and I use it for my personal blog and some minor websites.

Has anyone used Hugo for something other than a blog? I am looking for some stories like using Hugo as a REST-API or anything other more creative similar to this:

https://forestry.io/blog/build-a-json-api-with-hugo/

I used Hugo 0.12 to build a 2200+ page non-blog website a few years ago, with Disqus commenting. Completely different than a REST api, but the jaw-dropping part was how quickly it all got parsed. Like under 2 seconds. Crazy fast.

That's insane. My <10 page Gatsby site takes 15-20 seconds :/

Not necessarily a fair comparison. A bit oranges vs apples there.

Most of the Gatsby time is usually doing bundling of css, js, etc with Webpack. I would imagine if you did that with a Hugo site you would run into the initial 15-20 seconds to bundle & then a few seconds to convert all your markdown pages into static HTML pages.

That said, I would assume Hugo still wins but not by near as much.

So you can argue that Hugo is much faster, if you don't have a use for Webpack on your site. If you don't want the fancy bells & features Gatsby provides, you should for sure pick Hugo over it.

Great point. Hugo does a bit more css processing now, but not nearly as much as Gatsby would.

there is a huge performance rearchitecture going on in Gatsbyjs - https://github.com/gatsbyjs/gatsby/pull/6226/

current benchmark: 25000 pages in 32 seconds.

I've got a wiki style site built with hugo. Source code is here (readme includes link to actual site): https://github.com/neRok00/mq-patrol

Can anyone recommend a good blog theme? Themes.gohugo.io does not seem to have anything super appealing to me

They've got a huge range of themes on there - you'll have to be more specific about your tastes

There's also the option to create your own https://gohugo.io/themes/creating/

Your request is akin to giving a developer the requirement to "make the thing" and expecting a fully-formed application that does exactly what you were thinking at scale.

You may wish to specify your exact requirements.

with a bit of CSS study and some experimentation, all of the themes can be turned into something appealing. Start with one that's close to what you like and dig in.

If you have any experience with web development, it's actually very trivial to create your own. I had absolutely no trouble putting together something simple for https://tomjwatson.com/. The code is available here - https://github.com/tom-james-watson/tomjwatson.com

I used the acedemic theme on mine > https://www.30platforms.com

I’ve been pretty happy with Hugo so far.

I wanted to use this before going back to Gatsby:

https://themes.gohugo.io/minimo/

Reply on news.ycombinator.com