[penglish1]

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.

[benatkin]

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

[regularfry]

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

[benatkin]

Reasonable, but not as effective IMO.

[prophesi]

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/

[annywhey]

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.

[jacquesm]

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.

[jscholes]

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.

[kqr]

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

[kaushalmodi]

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.

[eddieh]

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)

[rurban]

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.

[BeetleB]

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.

[esolyt]

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

[johnklos]

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?

[jacquesm]

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.

[2bitencryption]

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.

[scrollaway]

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

[edem]

Care to elaborate?

[KajMagnus]

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.