I recently completed a pretty fun little website[1] for the U.S. freight rail industry using Hugo, Vue.js, Nuxt, Vuetify, Chart.js and Netlify. It is open source on GitHub[2].<p>It will soon replace an aging version of the site[3] that was built with Sitecore CMS, .NET, and SQL Server.<p>At first I considered using Hugo to generate the HTML for the site from git-backed JSON/YAML/TOML files. But the quantity and complexity of the Golang templates was clearly going to be tedious, inflexible, and tough to maintain.<p>So I settled on using Hugo to generate a read-only REST API instead[4], based on a nice blog post I had read[5][6].<p>This freed me to use any front-end framework I wished, and I chose Vue, Vuetify, and Axios for their simplicity and productivity on this solo-developer project.<p>In the end I was quite happy with this combination. Hugo was incredibly fast and productive for ranging over and manipulating all of the JSON/YAML/TOML data files to produce the final read-only REST API JSON... after the initial learning curve with Golang templates.<p>And the front-end really just boiled down to some key Lodash transformations of the JSON into the various shapes of data that were needed for tabular reports and Chart.js graphs.<p>[1] <a href="https://app.rrpm.run/" rel="nofollow">https://app.rrpm.run/</a>
[2] <a href="https://github.com/railroadpm/site" rel="nofollow">https://github.com/railroadpm/site</a>
[3] <a href="http://www.railroadpm.org/" rel="nofollow">http://www.railroadpm.org/</a>
[4] <a href="https://api.rrpm.run/reports/bnsf/all" rel="nofollow">https://api.rrpm.run/reports/bnsf/all</a>
[5] <a href="https://discourse.gohugo.io/t/build-a-json-api-with-hugos-custom-output-formats/11523" rel="nofollow">https://discourse.gohugo.io/t/build-a-json-api-with-hugos-cu...</a>
[6] <a href="https://forestry.io/blog/build-a-json-api-with-hugo/" rel="nofollow">https://forestry.io/blog/build-a-json-api-with-hugo/</a>
We switched the Let's Encrypt website from Jekyll to Hugo. We did it primarily for i18n support (Jekyll does not support translation), but it would have been worth it just to avoid Jekyll's ruby dependency nightmare. Hugo is a single static binary, so simple.
I don't see myself moving from Jekyll for a long time.<p>And it's mainly because of Jekyll-Assets. It's just too useful for not only bundling assets but effortlessly md5 tagging everything for caching on the nginx side of things.<p>Hugo and others have nothing like this, and rolling your own set up isn't feasible for that because for it to be done right, it needs to be supported at the generator / plugin level so your template helpers know how to deal with looking things up from the untagged file name.<p>My site has about 170 blog posts and dozens of other pages and Jekyll's incremental reloader refreshes in a little over 2 seconds. That's about 1 second longer than I'd like to see a blog post get live reloaded in development, but it's good enough.
FWIW, I achieved something like live reloading in Jekyll using an additional config file.<p>_config_local.yml:<p><pre><code> html_refresh: true
html_refresh_rate: 5
</code></pre>
Then, I appended the config via:<p><pre><code> jekyll serve --config _config.yml,_config_local.yml --force-polling
</code></pre>
And then did a check in my header include:<p><pre><code> {% if site.html_refresh %}
<meta http-equiv="refresh" content="{{ site.html_refresh_rate }}">
{% endif %}
</code></pre>
You can find a working example in my blog's repo[1].<p>[1]: <a href="https://github.com/woodruffw/blog" rel="nofollow">https://github.com/woodruffw/blog</a>
I like the speed and flexibility of Hugo. It doesn't force you into the blog format like Jekyll does. Jekyll has collections but collections don't have all the features of posts. I keep coming back to Jekyll because of the relative link support that works across VS Code, Github, and Jekyll. Hugo added support then removed it.<p><a href="https://github.com/gohugoio/hugo/issues/1921" rel="nofollow">https://github.com/gohugoio/hugo/issues/1921</a>
I'm in the process of creating a new blog and site (I have python, vue, nuxt background) which maybe will have more non technical authors and dynamic content in the future and after many iterations (looking deeply at Hugo, Lektor, Forestry and even Wordpress [headless]) I will probably go to a<p>open source headless CMS Strapi <a href="https://strapi.io" rel="nofollow">https://strapi.io</a> and Nuxt.js frontend.<p>If anybody knows a python and flask based headless CMS let me know!
I have an interesting Jekyll performance story. I was trying to build a website [1] that was going to be the new destination for git information. The site is a static site and I figured that since Jekyll was integrated into GitHub, it would be simple. My script downloaded all of the git documentation from the linux kernel website, did some parsing of the HTML files adding front matter, and then tried to generate the site.<p>My Jekyll(Ruby) script was running over a day and never finished. Hugo(Go) ran in about 5 minutes. Granted there are over 10,000 pages being generated by Jekyll but it was so painfully slow, I couldn't possibly have a daily CI system that generated the site.<p>I'm still fixing some https issues with GitHub static site hosting, but it should be working soon.<p>[1] - <a href="https://github.com/dvcs/gitdvcs.com" rel="nofollow">https://github.com/dvcs/gitdvcs.com</a>
Speaking as a newbie (python and R mostly) who just wants the blogging software to blog, I use Jekyll because it’s the default choice. Yes there are python options but I don’t want to program the software - my programming energy is already spoken for.<p>I don’t care about the speed differential.<p>However if Hugo is actually easier somehow, well that would be tempting.
I really like Hugo and use it for one of my websites. It is refreshing to get such a fast website.<p>Where I find Hugo lacking though is I have found it very difficult to theme. Hugo has a very particular way of doing things with sections, sub-sections, leaf nodes and branch nodes, and a very particular folder structure where having an index.md file does one thing, but an _index.md file means something totally different. This would be fine if the docs were extensive and explained this clearly but they are very light in this area and most knowledge seems to be burried in individual disqus posts and other people's heads. I am sure it makes sense to people already familiar to Hugo, but trying to grok it all as a new-comer has been difficult.<p>As a result working out how to do even trivial things such as listings of pages in grandchild-directories, or even just having a list of child pages with other textual content has been a terrible struggle for me. Existing themes are invariably horrendously out of date, so trying to learn from those is also difficult. To this day on my site, if you go to specific directory paths there is literally a blank page because for the life of me I cannot work out how to make Hugo display just a simple list of posts in grandchild directories. It is infuriating! Perhaps it is my fault for wanting a semantic directory structure (e.g. domain.com/subject1/subject2/actualContentInHere/ and the pages for subject1/ and subject2/ are literally blank).<p>TL;Dr - good but if you want to do more than CSS tweaks on an existing theme then you're in for a challenge.
Few months ago, I migrated to Hugo after several years on Jekyll, and I'm so glad I did. While Hugo does have many flaws, I love it for its simplicity, which is also the reason why I chose static website generation over Wordpress or CMS.<p>I still like Jekyll and I might use it for blogs that has more complex requirements for building the site. However, my blog is simple and I just wanted to generate my site quickly (and boy is it quick). Also using the template was very easy, and I was able to migrate my Jekyll theme to Hugo without too much trouble.
We’re running our blog on Jekyll. Is there any good reason to migrate to Hugo? In the article I’ve found this comment:<p><i>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)</i><p>Other than 3., all other points are valid for Jekyll as well. So why move, other than for the sake of just migrating (which can be fun too...)?
Hugo is a fantastic tool and I would choose it again. However there is a little annoying bug for years: If you let Hugo create a table of contents it adds an unnecessary level of nesting, if the highest level of content headings is h2. This is pretty common if you use h1 for the page title (that shouldn't be repeated in the table of contents).<p>But besides that Hugo is a feature rich, fast and easy to install tool.
I've used pretty much every product out there for static site generation, and I gave up.<p>So I created [0] Statik.<p>I dont mind manually building out the mardown/razor/etc. In the end, I get exactly what I want, with no overhead or heavy abstractions weghing me down.<p>[0] <a href="https://github.com/pauldotknopf/statik" rel="nofollow">https://github.com/pauldotknopf/statik</a>
I'm surprised nobody mentioned Hakyll [1] here - a great Jekyll alternative that's fast(ish) and supports hot-reloading. You do have to like / tolerate Haskell though (this polarises opinion pretty fast...)<p>[1] <a href="https://jaspervdj.be/hakyll/" rel="nofollow">https://jaspervdj.be/hakyll/</a>
The recent livereload feature on Jekyll coupled with running Jekyll locally in Docker works well me.
<a href="https://davemateer.com/jekyl/2018/01/25/Jekyll-and-Docker.html" rel="nofollow">https://davemateer.com/jekyl/2018/01/25/Jekyll-and-Docker.ht...</a>
I agree to most of your points. I too recently moved from jekyll to Hugo and I know I did not make a bad choice. It is awesome and making me to write more. Hosted on github pages.
<a href="https://www.rammy.in" rel="nofollow">https://www.rammy.in</a>
The momentum around static site builders is around the react based builders like Gatsby.<p>Since you are going to spend a huge amount of time writing js code for the front-end anyways, it makes sense for the whole stack to be js.<p>We moved from Hugo to Gatsby for primarily this reason. I can now handover the site to js folk ...instead of having them learn golang based templates.
Aaaaaand this is why I don't jump on the latest frameworks anymore... I can almost hold my breath long enough for a framework to go out of style.<p>The first time I read about Jekyll was here, and now already something better has come along, my brain just gave me that tiny little mental high-five on my decision to no longer live on the bleeding edge
SSGs got competition from zero configuration build tools like Parcel. <a href="https://medium.com/@chesterhow/building-a-static-site-with-parcel-part-1-de5032c6bba7" rel="nofollow">https://medium.com/@chesterhow/building-a-static-site-with-p...</a>
I see these articles come up quite often yet it makes no sense to switch to hugo. I also tried it because I was fed up with Ruby (not Jekyll). It turns out that the tedium of implicit hell and cryptic templates which comes with hugo makes it much worse than the occasional bumps with upgrading Jekyll. Hugo is like choosing Scala (which is a baroque abomination of implicit stuff) over Kotlin (which is a pragmatic language). I think the problem here is bias. When you are fed up with something you tend to see everything else through rose colored glasses. See hugo for what it is: a tedious, cryptic unintuitive and dumb static site engine.