Why I do not like Hugo
blog.flameeyes.eu
blog.flameeyes.eu
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.
> 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.
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.
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 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.
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.
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.
> 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
And with a host like Surge or Netlify you can run an entire site for just the cost of a domain name.
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)
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.
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.
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)
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.
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
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.
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).
Not Wordpress wysiwyg but still pretty nice.
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.
Edit: Downside(s) would include that $webmaster has to figure out whether to render content at browser or though "ssr".
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 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."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 rolling out a feature soon that will allow you to specify the version of Hugo you're running.
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?
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).
It uses liquid for templating, and emulates a few plugins.
It currently works on some sites, not others – YMMV.
Edit: Here's the full code from one of my Makefiles:
files := $(patsubst %.md,%,$(wildcard *.md))
all:
for f in $(files); do \
pandoc -s -o $$f.html --template=template.html $$f.md; \
doneYou can view the Pandoc html5 default here: https://github.com/jgm/pandoc/blob/master/data/templates/def...
They gave me the Docker image to debug but it's useless because without sudo access, I can't do anything useful.
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...
It is also many times faster than Jekyll. Both were the reason,we chose Hugo.
Also they all try to build a whole site when I just need to create some HTML files and put them into existing directories.
OP please change the title to make sure it matches the actual blog.