Hacker News new | past | comments | ask | show | jobs | submit login
Why I do not like Hugo (flameeyes.eu)
82 points by luu on Aug 13, 2017 | hide | past | favorite | 78 comments

This can't possibly have taken less to write than changing the capitalization of one letter, overriding a default, and reverting a commit (or even better, contributing a config option for the desired behavior!).

And I say this not to flame about the author, but because it's a remarkable trend in the industry to complain (vocally!) about barely breaking changes in Open Source software.

There is of course the angle of "you're getting it for free, for LTS buy a commercial product", but even more interesting to me is how it condemns projects to never moving, until they feel legacy, and we have to move on to something new.

> about barely breaking changes in Open Source software.

I get the sentiment, but I'm immediately recalling times users have been spurned by projects that just didn't listen. In that light, this feels like a subjective statement.

I can tell you I'm racking my brain right now trying to invoke custom sphinx-doc builders programatically. And I get absolutely zero consideration in the issue tracker. Why? Because 99% of the cases of sphinx are invocation through ReadTheDocs and the project's Makefile. They don't care whether their internals are intuitive or not.

To most, it looks incredibly trivial. But I have a legitimate case to use sphinx this way, and they flip when I suggest adding an argument to insert a custom Builder. No, I have to create a side effect by inserting an extension, which registers the builder as a string, and then figure out why I'm not printing even basic debug statements.

I seriously only have the intention of making life easier for others. The internals of docutils and sphinx are no simple feat to understand.

Eh, other than my own personal problems, which I at least made patches for, there's gnome's spatial fiasco (https://www.osnews.com/story/7344). So, every time I did a gnome install I'd go into preferences to 'fix' it. Untold others did too.

I have sympathy toward open source projects not being able to change internals due to fear of introducing regressions and keeping code maintainable and (to a point) pragmatic. My point is, while there is people who pick small gripes over edge cases, there are simple little things that can cause headaches to users.

Yeah my impression was here's a guy using a free tool that is the product of a lot of work by a lot of people and now is whining that their vision for the product isn't exactly the same as his.

I have no quarrel with the author writing a blog post about his opinions. Also, every open source project has its complainers (paradoxically, the less money people pay, the louder they complain). No open source project survives longer than a year or two without learning to separate the signal from the noise, and tune out the outliers.

What does put me off though, is the trend toward "clickbait" headlines even for personal blogs.

"Why I'm Leaving X"

"X Considered Harmful"

"Farewell to X"

"Why I Do Not Like X"

I guess you just have to do this in 2017, if you want to get anyone to click your links and read your stuff. But the web feels dumber for it.

Serious question: If "Why I do not like X" is clickbait, what isn't?

It's not about the fact that something changed, but what changed. Full text to summary is quite the change to do based on -- who knows what? What progress, what advancement do you see here? And changing the default number of items from 15 to unlimited? I mean, not 50, not 100, not 500, but infinite? I see no purpose, just pitfalls.

> even more interesting to me is how it condemns projects to never moving

Oh yeah. Criticize any random silly move and you're against any and all progress, ever.

Hugo is still at 0.x. Hasn't stabilized yet. Breaking changes are to be expected.

I ask how this weren't bad and silly changes. When we can't even discuss why we are doing what, why not get rid of version numbers, too?

But there were some discussion and reasoning behind the changes. For e.g. RSS limit, see https://github.com/gohugoio/hugo/issues/3145. Nobody was against it, as far as I can see. If someone think it's a mistake, I guess opening an issue on GitHub (where devs can see it) would be more useful than complaining elsewhere?

> Oh yeah. Criticize any random silly move and you're against any and all progress, ever.

Not this person, or that person, but after you add all of the complaints together, the aggregate could be against any change at all. That isn't saying "don't change", but it does suggest that the promise of forking and fixing is not being realized, perhaps because not enough people have the combination of time, interest, and ability to do so.

Right now, people don't even have the interest to notice the good points he's making: these are dumb changes. The devs could have noticed that before making them. But instead, this guy took the trouble to write about it. Maybe he likes that more than asking a "fix" to be accepted when it's not even a bug fix, but a change they made for whatever reason.

And the stuff about the two natures of RSS feed doesn't belong in commit logs anyway, it belongs on a blog... but it seems the promise of communicating ideas with blog posts has not been realized, either. He made sensible criticism, it wasn't received sensibly. Saying "submit a patch instead" is just as valid as replying "write a blog post about it instead" when someone submits a patch. He doesn't like Hugo, for these reasons. Not terribly interesting, but fair enough, and nothing is too small to be addressed on its own actual merits.

I love Hugo. By far it is the fastest blog engine that I have seen. If I need a custom shit done then I will fork the repo and build the needed stuff myself.

Bitching about the free software is unethical. Moreover, the source code is accessible. Change whatever code if you don't like it.

In my experience I've had PRs rejected, so what? People have opinions and not everyone one think of your issue as the blocker. Move on.

"Why don't I like scrambled eggs at that place" - no one cares. Make them yourself or go to another restaurant.

> Bitching about the free software is unethical. I disagree. Of course you should try to keep the language nice and show examples of things that cause you problems, features you are missing or things you don't like but the would be very little progress in OSS projects if no one are allowed to comment at all.

Hence me saying, fork it and change whatever you don't like.

Similarly, if you don't like someone's blog, don't read it. Or at least tell them, not us. Write a better blog or read another one.

> A Reverend Donald Wildman in Mississippi heard something on the radio that he didn't like. Well, Reverend, did anyone ever tell you there are two KNOBS on the radio?

-- George Carlin

Not following the analogy here... But one thing is to post a blog, another is to post a blog and share it on hacker news to generate feedback.

No, it's not. Plus the person who wrote the blog post isn't the person who posted it to HN.

Slightly OT, but Is Wordpress still the only real solution for a professional looking blog for those that want a wysiwyg editor? My wife is starting a blog and wants me to set it up for her.

My go-to replacement for Wordpress is Grav. It is a flat file cms, which means that it doesn't require any database. All posts are stored in markdown files with yaml front matter. However there is also an admin GUI frontend for non technical users.

Not using a database makes it really simple to install or migrate servers (just copy the directory).

On the other hand, being a dynamic PHP app means there is no explicit build step needed, and you can build any kind of plugin that you need.


I'm building something that you might find interesting. Pragma (https://pragma.build), comes with a browser based Medium style editor and static page publishing by default.

I've been running an invite only private beta for a few months now, and most of our early adopters were tech-savvy people who were asked by their friends/family to build a site. They love it because it's less setup and maintenance burden for them. I also plan to open source the project in the coming weeks, so you'd have greater flexibility of hosting it anywhere.

If you like to give a try, request an invite on site (pragma.build) or send a DM (@PragmaApp) on Twitter.

I've asked for an invite years ago.

Oops...Resent the invite.

Oops, I was invited already? I've probably messed things up and deleted the email then. Sorry.

A static site generator like Jekyll or Hugo paired with a CMS-as-a-service like Forestry or Contentful makes for a fast, no maintenance Wordpress alternative.

And with a host like Surge or Netlify you can run an entire site for just the cost of a domain name.

That doesn't really answer the question - no static site generator {that I know of} is WYSIWYG in the same way as Wordpress. Yes, you can train people how to use a generator, but compared to a dynamic CMS they have a _much_ steeper learning curve {based on my experience training people about web publishing}.

The closest I've seen is using Sandstorm with their static Wordpress site publishing but it's still nowhere near as smooth as plain Wordpress.

(Edit: let's add some qualification because downvoting)

Lektor (https://www.getlektor.com) is a static site generator with a simple admin interface (with WYSIWYG editor for markdown) which can be run locally. Publishing can also be done via a button in the UI. For even more user-friendliness, the site can be stored in Dropbox, so the user doesn't even need to know git.

The static generator is completely hidden to the end user. They log in, click add new post, add some text, style it in Markdown or HTML, upload a few images, add a few tags and click publish. Forestry commits the changes and Netlify runs a build. All the user sees of this is that their new post is now published.

When I first started using static sites I would have agreed with you: there's no way I'd hand a normal user a markdown editor and a git repo and expect them to get on with it. But these new services do, in my opinion, solve the experience problem.

However Wordpress is really good if you want to leverage the module ecosystem and do more complex stuff further down the line.

Having used Wordpress for years I get excited about static sites' speed, simplicity and lack of constant security updates but it's not a one size fits all situation.

Sandstorm also has a static producing Ghost instance, which is pretty decent, yet very dated in it's version.

What's the difference of Forestry and Contentful? I've heard good things about Contentful, but I haven't heard of Forestry.

Co-founder of https://forestry.io here.

Forestry.io is a Git-based CMS that commits content changes to your repo (and optionally builds/deploys your site). Contentful is an API-based CMS, that stores your content and requires you to query their API during/after build time.

Oh, ok that makes sense.

So you would use Forestry if you're hosting static HTML from CMS, and Contentful for when you need an API for the CMS.

(disclamer: I've never used CMS before so I don't really know how it works)

Is your service coupled with Hugo?

Not sure what you mean by "coupled", but we support both Hugo and Jekyll sites.

Ah, sorry, thought it was something more like Contentful that provides an API.

I've not used either, but Forestry seems like a CMS-to-static-pages tool while Contentful is a CMS-to-API tool.

And Netlify also offers Netlify CMS, which can accomplish the web-based composing urge.

Squarespace is wonderful from a WYSIWYG standpoint, and doesn't require immersing yourself in the WordPress ecosystem.

Kirby CMS is the answer if you can install a plugin for wysiwyg and deal with Disqus for comments. There are Kirby plugins for comments that get saved locally, but I haven't experimented with them yet.

I'm happy with the abstraction that https://www.contentful.com/ provides; be it a personal static site or more complex integrations which involves multiple content feeds. You get to define a content model and then just create away [within the limits of said model]. Their pricing is fair too (read: free for most).

Edit: Downside(s) would include that $webmaster has to figure out whether to render content at browser or though "ssr".

I've been experimenting with hosting the site content on GitHub, creating and editing posts with https://github.com/fiatjaf/coisas and auto-publishing with https://docs.travis-ci.com/user/deployment/pages/

WordPress hosted on wordpress.com without any 3rd party plugins is pretty solid. But ghost might be a decent alternative. If you want to self-host, you might want to consider cmsmadesimple.org as an alternative to wordpress (it's also php, but as the name implies it's simple - it's more of a cms than wordpress - but in a good way - it's more sensible if you want to customise it).

WordPress is probably not the only one but the issue with others is that at some point, you hit a wall with them. It is really hard to beat the ease of setting up WordPress (tons of 1 click hosts), ease of extending functionality (need social share? There is a plugin for that). If you need a blog for a non technical person, you just cannot beat WordPress. The codebase may be ugly but who cares.

Well, a reason to care about the ugly codebase is that unless you're 100% satisfied with somebody else's theme out of the box, you're going to be tweaking it in a child theme (or a full fork), and wow it's ugly.

But having said that, the ecosystem of WordPress is really hard to beat. The original linked post complains that WordPress won't do Markdown without a plugin, but y'know, so what? Jetpack gives me Markdown and great site statistics without Google Analytics. Out of the box, I get a reasonably solid taxonomy system with per-category RSS feeds, threaded comments with Gravatar support, and an API that lets me publish drafts directly from offline clients (including Ulysses, the writing app I was already using). More plugins give me Akismet anti-spam, microformats, webmentions, and per-post crossposting to Tumblr and Dreamwidth. (And Facebook, Medium, and a dozen other systems, if I chose to use them.) There are a lot of things I don't love about WordPress, but the reality is that it's damn hard to beat its user experience.

I'd love it if something else stepped up to be a modern WordPress, but Jekyll, Hugo, et. al. just aren't it. (They're terrific at some things--I maintain a different site with Lektor, using it for things that WordPress wouldn't actually be very good at--but it's not a blog.) Ghost is the closest attempt I'm aware of, but between their launch and their recent 1.0 release, they refocused on being a platform for "building and running a modern online publication. I can't help but feel there's still a real opportunity out there for "modern WordPress competitor," although I don't know if it's a market opportunity--which is, one suspects, why it remains unfilled.

Hi guys, we just developed a SaaS (https://www.hardypress.com) to have the best of both worlds (static site + wordpress), but fully automated and hosted. We also seamlessly support Contact Form 7, and we take care of scraping your website’s pages and augment the search box to provide instant suggestions so, for most websites, everything will work just fine, even if the site is completely static. If you want to give a try, I would be happy to hear some feedbacks from you :-)

> The codebase may be ugly but who cares

Code quality matters indirectly here. Wordpress is known for it's massive number of security flaws. If you don't watch for new versions and update regularly ( and who has time for that ? ) consider yourself hacked

Check out Publii. Desktop app for generating static sites/blogs for Mac/Win with some very attractive themes.

Ghost is the main competitor to work, comes as both hosted and self hosted.

The problem with static sites is that you have to regenerate the site each time you make an update or new post... Wordpress just allows you to update it from the admin panel.

Depends on what youre using to host the html files, but you can probably deploy in two commands.

1. generate your files

2. copy these files to your host

Put these in a script, and your workflow becomes: update your content, then run your script.

My experience with Hugo through v0.17 was that it takes ~1ms per post to generate. IIRc that was one of the major reasons why the author wrote, vastly increase the speed of regenerating the site.

Right. But I can update my Wordpress site from my phone in China without a laptop running Hugo...

Maybe things are getting better these days (?), but at various points throughout its history, anyone could update your WordPress site from their phone in China.

Right, and that's a truly killer feature if you happen to need it.

Hugo doesn't address that problem at all, nor do Jekyll, which I currently use, and the other similar tools I've looked at.

However, the missing step there (of rendering the static site and publishing it) seems well suited to being done "in the cloud" then on the client device where the posting/editing/typo.

If you have a machine or VM on the Internet to use, this is not difficult to set up for yourself (any computer-proficient user with a little time can do it).

But doing that is also nowhere near as trivial as WordPress makes it (any person at all can do it).

That seems like exactly the gap Netlify wants to fill with their Netlify CMS (and a bunch of other options, depending on your exact needs).

Interesting; thanks. I just signed up for forestry.io (which I also learned of in this HN thread), I will check out Netlify also.

Some hosts like Gitlab Pages or Netlify will run hugo for you. So you can use an online git editor, save, and it'll deploy automatically.

Not Wordpress wysiwyg but still pretty nice.

TryGhost. It's still limited in features, but it is good for simple blogs.

Are there any walkthroughs from zero to all done of best practices to setup a product website using a static generator (Jekyll, Hugo, or whatever) rather than a blog?

I started looking at the Hugo "quick start"[1], but then apparently the right way to work things as branches for GitHub pages is more choices[2]. Grabbing a theme that was optimized for more of a product page than a blog led to another warning[3] that the normal documentation wasn't going to be helpful. After that, I decided it would be best to ask for help!

[1] https://gohugo.io/getting-started/quick-start/

[2] https://gohugo.io/hosting-and-deployment/hosting-on-github/

[3] https://themes.gohugo.io/kube/#GettingStarted

  "There are a few concepts this theme employs to make a personal documentation site.
  It’s important to read this as you may not see what you expect upon launching."

I'd recommend Jekyll for that. It's stable and established for such web sites. I used it for a product Web site years ago and it worked fine. If I remember correctly, there's even a tutorial in their official docs.

I run a small blog using Hugo. Some weeks ago I published a new article. All was well, until I visited it a few days ago and noticed all but the very most recent article link was broken.

Apparently Hugo decided to transition article urls from PascalCase to lowercase without any sort of migration path, warning, or indication to say that things were about to break.

You would think at least some thought would have been put into a migration path.

We're building a WordPress-like CMS for Hugo sites. I'm curious if this would improve the Hugo experience for you (commits to your repo, supports media uploads, Markdown, etc).


We're rolling out a feature soon that will allow you to specify the version of Hugo you're running.

I'm curious, since you have experience supporting both Hugo and Jekyll: which would you recommend?

Say I have a personal blog I've been maintaining for 15 years in BlogMaster 3000 for Windows 95, and now I want to make it modern and static and use forestry.io to handle the editing and publishing parts. Are there significant differences in terms of capabilities or ease of use depending on which static blog engine is used for the build step?

TLDR; If you care about build times, Hugo. Otherwise, Jekyll.

For instance, we had a user who had a Jekyll site with 2000 pages. It took Jekyll about 5 mins to compile/build it. After migrating to Hugo it took < 1 second to build.

If you don't care about build times, Jekyll has a great community, plugins, and IMO, superior templating syntax (liquid).

My “learn go” project was a Jekyll clone with fast build times https://github.com/osteele/gojekyll

It uses liquid for templating, and emulates a few plugins.

It currently works on some sites, not others – YMMV.

OT, but what is the best static site generator for mostly standalone pages except Jekyll (which broke Netlify)?

I don't want to get into any arguments about "best", but what works best for me is to write the pages in Markdown and use a Makefile to convert them all to html. There's always overhead with projects like Hugo, concerns about upgrading, and rough edges with respect to customization. If you just want to create standalone pages, a Makefile and Pandoc is about as simple and flexible as you can get.

Edit: Here's the full code from one of my Makefiles:

  files := $(patsubst %.md,%,$(wildcard *.md))
    for f in $(files); do \
      pandoc -s -o $$f.html --template=template.html $$f.md; \

If you want something a little more involved, https://jaspervdj.be/hakyll/ is a static site generator that uses pandoc under the hood. Uses a Haskell DSL

Does that template.html has some css links? if so, is that something that comes with pandoc?

It's a modification of the default Pandoc template. I add css to it directly, but it can load css files if you wish. Think of it like this - there's a $body$ statement in the middle of the template. The html generated by Pandoc goes there. Everything else in the template file stays there.

You can view the Pandoc html5 default here: https://github.com/jgm/pandoc/blob/master/data/templates/def...

My https://github.com/fiatjaf/react-site is imperative instead of declarative, maybe that will suit you.

By that I mean you write generator script[1] and use the helper functions `listFiles`, `generatePage` and `copyStatic` to generate the pages you want with the template/configuration you want at the path you want. That means you can render content not only markdown files, but any source whatsoever, and combine the sources in any way you like.

[1]: https://github.com/fiatjaf/levypla/blob/1407b110228387e4a4b7...

I use ikiwiki (https://ikiwiki.info/) for my blog (http://per.bothner.com/blog).

Hugo is a single binary that works on Linux, windows and osx. That's a godsend compared to setting up Jekyll - which needs you to setup ruby and then install all dependencies.

It is also many times faster than Jekyll. Both were the reason,we chose Hugo.


Jekyll works well with Netlify - you might just have needed a Gemfile or the like?

Under very specific circumstances my standard build setup, which works on my machine, their machine and one of their website plans, fails on another plan - some pathing issues I think.

They gave me the Docker image to debug but it's useless because without sudo access, I can't do anything useful.

I went through dozens of static site generators including Hugo and everything was so complicated and opinionated that I ended up writing 500 lines of my own.

Also they all try to build a whole site when I just need to create some HTML files and put them into existing directories.

The title of this post is misleading. It feels as if Hugo is plagued with tons of loads of problems (especially when so many people have upvoted!) where it is just ONE problem. Just ONE which is not even that hard a thing to resolve.

OP please change the title to make sure it matches the actual blog.

Sorry, that was my mistake. Fixed now.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact