10 ms·

Migrating from Jekyll to Hugo

134 points by dguo 8y ago

declnz 8y ago
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...) [1] https://jaspervdj.be/hakyll/ https://jaspervdj.be/hakyll/
nickjj 8y ago
I don't see myself moving from Jekyll for a long time. 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. 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. 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.
- biggestlou 8y ago
  An asset pipeline (and templatized at that) is being added to Hugo as we speak. Just Sass support to begin with but more later. Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero.
  - tny 8y ago
    Why do you say that Jekyll is abandonware?
    - giancarlostoro 8y ago
      I'm curious about this too considering GitHub uses it for GitHub pages, I would assume they have a vested interest in maintaining Jekyll even if they had to fork it to improve upon it.
  - nickjj 8y ago
    md5 tagging at the Hugo level has been talked about since 2014 and it's still no where on the horizon. If SASS support still isn't out yet, who knows how long "later" is. > Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero. They are working hard on Jekyll 4.x and huge sites like Docker's documentation[0] use Jekyll. I'd still feel comfortable using it today. It really comes down to preference IMO. Jekyll is more than adequate to use for a blog or large site. If you like liquid's template engine and enjoy having the ability to write plugins in Ruby then it's a good match. [0]: https://github.com/docker/docker.github.io https://github.com/docker/docker.github.io
    - benatkin 8y ago
      If you have a CDN or Varnish, they can provide eTags, and you don't need an md5 in the URL, except to save the browser from doing a GET request and getting a 304 Not Modified. A few Not Modified requests served by a fast server is worth the tradeoff of not having to deal with an asset pipeline, or worse, overly aggressive caching, which is common in asset pipeline environments where the cache settings designed for md5 tagged assets inevitably get applied to non-tagged assets.
      - qw 8y ago
        That would cause issues when deploying new versions. Even if the CDN or Varnish serves an updated etag, the browsers could potentially keep using an older version from its cache. Not what you want when you just fixed important bugs. This has happened to me, even without aggressive caching. I suspect that even if you told the browser to revalidate on each request, you would end up in situations where the browser ignores it or is overruled by a corporate proxy. With a md5 in the URL, the browser would be forced to make a new request.
        benatkin 8y ago
        I've seen that happen, but I've seen people reset their browser caches because of misconfigured aggressive caching much more often. IMO max-age=0, must-revalidate is a much better choice for the average website/blog owner. For complex apps, setting up the asset pipeline can be worth the tradeoff. But Hugo is hardly a lower tier static site generator for not supporting this.
  - kipari 8y ago
    > which is essentially abandonware Could you please expand on this? This seems like something that requires a source.
  - nicoburns 8y ago
    Oo, that will be awesome. I use hugo for my personal website, and currently run the node-sass cli separately.
  - edem 8y ago
    The reasons to use hugo are negative. I only have cons to it.
- benatkin 8y ago
  Having few assets is better than having a fancy asset pipeline. https://www.gatsbyjs.org/ https://www.gatsbyjs.org/ supports code splitting and since it uses JavaScript, CSS generation libraries like styled-components, Glamourous, and JSS are available. That means only outputting the CSS and JS that are needed for the page. This is great for blogs where someone might only read one article. The Hugo community is working toward minimal assets too.
  - nickjj 8y ago
    > Having few assets is better than having a fancy asset pipeline. It's not about a fancy asset pipeline. It's taking app.css and turning it into app.a5fec617.css so that you can configure your web server to cache it forever. It's important to do this for CSS, JS and all of your images and other assets. Each blog post of mine has a cover image and with 170 blog posts, that's 170 blog images that need to be md5 tagged. The asset pipeline (transforming SASS into CSS and minifying everything) is just a nice convenience. It's also nice to be able to just write {% asset foo.jpg %} and end up with <img src="images/foo.34fbc1e9.jpg" width="256" height="256" alt="foo" /> in the HTML. Never having to manually set a height/width or alt tag (unless I want to manually override it) saves a lot of time.
    - benatkin 8y ago
      Without md5 tagging but with a reasonably configured web server, the browser gets an eTag in the response headers to the first request to load that cover image, and sends it in the headers to the second request and gets a 304 Not Modified response with an empty body. The size of the cover image is completely moot when comparing a proper Hugo config vs a proper asset pipeline config.
      - qw 8y ago
        The main advantage of a hash is that browsers will download the new version of your CSS/JS on the next page view, while still caching it «forever» If the url stays the same, you never know what version your visitors will get. You might publish a new version, but the user would not see it due to browser caches or proxies.
- kaushalmodi 8y ago
  > rolling your own set up isn't feasible for that because for it to be done right I do cache-busting > hugo > minification using a simple bash wrapper script. Though, in the coming week, Hugo might natively start supporting the cache busting and minification.
- Supermighty 8y ago
  Minification, fingerprinting (md5 tagging), and similar features are being worked on for Hugo, and should be avail soon: https://twitter.com/GoHugoIO/status/1009923838346514433 https://twitter.com/GoHugoIO/status/1009923838346514433
Odenwaelder 8y ago
I absolutely love Hugo.
jaas 8y ago
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.
- the_mitsuhiko 8y ago
  I built the actix.rs website with hugo and while I generally like it it has some bizarre things that make development harder than necessary. Sometimes it randomly refuses to build pages that worked before, until you realize it has something to do with it now picking up other templates. But no error message. And that you can't shell out to helper scripts makes it very restricted in so many aspects. I wanted to extract source examples from other code and preprocess it and the only way I could make it work was some really ugly go template code and that didn't even let me implement everything I want since they are so restrictive :( I really wish one could shell out to an executable to fill the gaps. As an example this is how code snippets are included. Sadly we cannot remove leading spaces on the lines to remove extra indentation, so now the source files look ugly :( https://github.com/actix/actix-website/blob/master/layouts/shortcodes/include-example.html https://github.com/actix/actix-website/blob/master/layouts/s...
- andy800 8y ago
  Thank you! The LE site is terrific (as is LE itself). Because it is open-source, I essentially cloned it for a professional association. https://casinoanalytics.org https://casinoanalytics.org Credit to LE is on the FAQ page. Thanks again.
- edem 8y ago
  And it is full of implicit stuff, cryptic templates, and the whole thing is pretty unintuitive. You also cant write plugins for it. Jekyll has i18n support I dont know what you are talking about.
inputcoffee 8y ago
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. I don’t care about the speed differential. However if Hugo is actually easier somehow, well that would be tempting.
- hnarayanan 8y ago
  It is significantly easier to setup because (in typical Go style) only requires you to download and install a single fat binary. You do not need to do what you're otherwise doing with the likes of Jekyll which involve a significant Ruby environment alongside to function. I've been using it for over two years, and this is the thing I like most about it. In addition: * Yes, it's super fast. * It allows for clean layout of code with different layouts for different sections: e.g. https://github.com/hnarayanan/harishnarayanan.org https://github.com/hnarayanan/harishnarayanan.org * It's got a really friendly community for support.
- nyolfen 8y ago
  as someone with relatively rudimentary skills who tried and failed two or three times to get jekyll working on a throwaway vps, hugo is indeed very, very easy.
kchoudhu 8y ago
I feel like people spend more time migrating blogging engines than actually blogging.
- dvlsg 8y ago
  At least then you can blog about the blogging engine migration.
  - confounded 8y ago
    I personally enjoy the grand tradition of nerds writing blogs only about how they set up a blog.
    - comboy 8y ago
      ham radio 2.0
    - kaushalmodi 8y ago
      I thought I would also end up just being one of those (I had a sort of setting-up the blog using Hugo post too). But lately my blogging on many other topics that I'm really passionate about has picked up. Writing in Org mode has really reduced the writing block for me. I'm so glad I switched from Octopress to Hugo about maybe 2 years back.
      - abricot 8y ago
        Have you at least blogged about using org-mode?
        kaushalmodi 8y ago
        No, I got into developing an Emacs package that exports Org mode to Hugo-friendly Markdown - ox-hugo. Here's the package homepage created using Emacs/Org mode + ox-hugo + Hugo: https://ox-hugo.scripter.co/ https://ox-hugo.scripter.co/.
- 8y ago
pknopf 8y ago
I've used pretty much every product out there for static site generation, and I gave up. So I created [0] Statik. 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. [0] https://github.com/pauldotknopf/statik https://github.com/pauldotknopf/statik
- superrad 8y ago
  I believe there's a python static webpage generator that's been around for a while that already makes use of that name: https://github.com/thanethomson/statik https://github.com/thanethomson/statik
  - pknopf 8y ago
    I realized that after I made it. And I don't care :)
slathrop 8y ago
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]. It will soon replace an aging version of the site[3] that was built with Sitecore CMS, .NET, and SQL Server. 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. 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]. 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. 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. 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. [1] https://app.rrpm.run/ https://app.rrpm.run/ [2] https://github.com/railroadpm/site https://github.com/railroadpm/site [3] http://www.railroadpm.org/ http://www.railroadpm.org/ [4] https://api.rrpm.run/reports/bnsf/all https://api.rrpm.run/reports/bnsf/all [5] https://discourse.gohugo.io/t/build-a-json-api-with-hugos-custom-output-formats/11523 https://discourse.gohugo.io/t/build-a-json-api-with-hugos-cu... [6] https://forestry.io/blog/build-a-json-api-with-hugo/ https://forestry.io/blog/build-a-json-api-with-hugo/
- Avshalom 8y ago
  Pretty sure you have conflated the abilities of the half dozen frontend frameworks you added (for simplicity) with the the backend you replaced. ".Net" (not actually a specific backend) and an rdbms are not in any significant way a friction against a REST api. Mean while the only noticable difference between the sites is the front end.
  - slathrop 8y ago
    My comment above was intended to add some value and perspective on using Hugo in a real world business/industry/paying customer website scenario... something beyond a personal blog. So RE: the main discussion here about Jekyll and Hugo and static site generators (SSGs), I think that if you take a moment to consider the difference between the SSG/JAMstack approach vs. the traditional "build the response on every request" back-end approach (and I'm not picking on .NET and SQL Server there, I've developed many sites using them myself) you'll see that there are some huge differences[1]. I think the most important difference is that with SSGs and JAMstack, your back-end code only runs at build time, on free build server infrastructure. There is no runtime back-end code, and therefore you can operate these JAMstack sites, at scale, at zero or near-zero operating cost. In the case of my customer, I estimate I saved them $100K over the life of this new site. Of course, your use-case must align with this sort of architecture. Not every site can or should be totally re-generated when content is changed. And importantly for my customer, they did not have to sacrifice a nice, user-friendly content-management experience. I happen to be using Netlify CMS, but others like Contentful and Forestry are nice options too[2]. [1] https://youtu.be/uWTMEDEPw8c https://youtu.be/uWTMEDEPw8c [2] https://headlesscms.org/ https://headlesscms.org/
therealmarv 8y ago
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 open source headless CMS Strapi https://strapi.io https://strapi.io and Nuxt.js frontend. If anybody knows a python and flask based headless CMS let me know!
- tomd 8y ago
  Not Flask, but still Python: Wagtail - https://github.com/wagtail/wagtail https://github.com/wagtail/wagtail - is a popular headless CMS option. Michael Harrison from rice.edu / Openstax gave a great talk about this at last week's Wagtail Space: https://docs.google.com/presentation/d/1ZYMogOeXKCCmr7hDZnzx0euw2pD5VCwtv3a7zHB4FW0/ https://docs.google.com/presentation/d/1ZYMogOeXKCCmr7hDZnzx... https://www.youtube.com/watch?v=HZT14u6WwdY https://www.youtube.com/watch?v=HZT14u6WwdY
  - therealmarv 8y ago
    big thanks. Actually I worked for Openstax (Connexions) in the past but I think I did not met Michael Harrison at my time :)) I will definitely give it a testrun!
woodruffw 8y ago
FWIW, I achieved something like live reloading in Jekyll using an additional config file. _config_local.yml: html_refresh: true html_refresh_rate: 5 Then, I appended the config via: jekyll serve --config _config.yml,_config_local.yml --force-polling And then did a check in my header include: {% if site.html_refresh %} <meta http-equiv="refresh" content="{{ site.html_refresh_rate }}"> {% endif %} You can find a working example in my blog's repo[1]. [1]: https://github.com/woodruffw/blog https://github.com/woodruffw/blog
baxtr 8y ago
We’re running our blog on Jekyll. Is there any good reason to migrate to Hugo? In the article I’ve found this comment: 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) 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...)?
- Sir_Cmpwn 8y ago
  I'm not sure you understand. That quote is not listing Hugo's limitations, but rather it's strengths compared to Jekyll.
joeblau 8y ago
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. 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. I'm still fixing some https issues with GitHub static site hosting, but it should be working soon. [1] - https://github.com/dvcs/gitdvcs.com https://github.com/dvcs/gitdvcs.com
smoser 8y ago
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. https://github.com/gohugoio/hugo/issues/1921 https://github.com/gohugoio/hugo/issues/1921
rammy1234 8y ago
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. https://www.rammy.in https://www.rammy.in
- dguo 8y ago
  Hey, just giving you a heads up that the www version of your site gives me an SSL error. https://rammy.in https://rammy.in works though.
sytse 8y ago
If you want to use Hugo integrated with source control please know that our GitLab pages had support for our and 25 other static site generators.
- jobvandervoort 8y ago
  To be more precise, we support any static site generator, as we will serve any static content that you make available. So you can even use GitLab pages to e.g. display and easily share test output, documentation, or anything else. See: https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/ https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-page...
sandGorgon 8y ago
The momentum around static site builders is around the react based builders like Gatsby. 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. 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.
- akerl_ 8y ago
  Why would I spend a huge amount of time writing JS for the front-end?
  - sandGorgon 8y ago
    You have the choice to. If you use reactjs based frameworks, you get the same amount of upfront effort as Hugo. It's not harder. However build times are slower. But as your website complexity increases, you can leverage the reactjs ecosystem (both people and libraries). In Hugo, you get locked to their templating system. Which is nice...but very non standard and relatively non-Googleable.
- gschier 8y ago
  I went this way too. If your site has a dynamic/interactive frontend, Gatsby makes it super easy to build a static-but-interactive site. Another huge plus with Gatsby is that it uses React's server-side-rendering to ensure that the site is still seo-friendly. If you have more than a few snippets of JS on your site, Hugo comes up way short. It's great for simple things though.
- slathrop 8y ago
  I ended up with a hybrid approach where Hugo and Golang templates are only for building the data (TOML files) into the required JSON for a read-only REST API. The remainder of the solution is all JavaScript (in my case Vue and Nuxt instead of React and Next). I came very close to switching to Gatsby early on, and I am very curious to know how my project[1] would have gone with Gatsby instead of Hugo. I get the impression that for the data manipulation (avoiding complex Golang templates that generate HTML) and for build speed, Hugo takes it. Certainly if you are working in React the simplicity of a single framework is the way to go, as you did. I also kind of felt a little more weird about mixing Gatsby and React with my preferred front-end framework, Vue, than I did about having to combine Golang template logic in one layer (API) with JavaScript in another layer (App). [1] https://github.com/railroadpm/site https://github.com/railroadpm/site
RobertRoberts 8y ago
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. 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
davemateer 8y ago
The recent livereload feature on Jekyll coupled with running Jekyll locally in Docker works well me. https://davemateer.com/jekyl/2018/01/25/Jekyll-and-Docker.html https://davemateer.com/jekyl/2018/01/25/Jekyll-and-Docker.ht...
mattlondon 8y ago
I really like Hugo and use it for one of my websites. It is refreshing to get such a fast website. 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. 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). TL;Dr - good but if you want to do more than CSS tweaks on an existing theme then you're in for a challenge.
- jotaen 8y ago
  I second this. I built my own template from scratch and even though my layout structure is quite simple it consumed a lot of time to find out how where to put files in order to make things happen. I agree that better documentation would have helped, but it would be also great if Hugo was more (explicitly) configurable instead of purely relying on conventions. (Once setup though, I continue to enjoy Hugo – it’s fast and mostly stays out of one’s way.)
- eevilspock 8y ago
  Matt and jotaen, email me if you want to try out some changes I've made to Hugo that make it simple and easy without losing any power.
deltron3030 8y ago
SSGs got competition from zero configuration build tools like Parcel. https://medium.com/@chesterhow/building-a-static-site-with-parcel-part-1-de5032c6bba7 https://medium.com/@chesterhow/building-a-static-site-with-p...
edem 8y ago
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.
cryptos 8y ago
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). But besides that Hugo is a feature rich, fast and easy to install tool.
- otterpro 8y ago
  I don't know if this is the same issue, but there is a workaround in https://github.com/gohugoio/hugo/issues/1778 https://github.com/gohugoio/hugo/issues/1778. The TOC had been driving me crazy, and I had just learned to live with it for now, but I think the workaround can address some of the issue.
otterpro 8y ago
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. 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.

134 points by dguo 8y ago

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...) [1] https://jaspervdj.be/hakyll/ https://jaspervdj.be/hakyll/

nickjj 8y ago

I don't see myself moving from Jekyll for a long time. 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. 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. 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.

biggestlou 8y ago
An asset pipeline (and templatized at that) is being added to Hugo as we speak. Just Sass support to begin with but more later. Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero.
- tny 8y ago
  Why do you say that Jekyll is abandonware?
  - giancarlostoro 8y ago
    I'm curious about this too considering GitHub uses it for GitHub pages, I would assume they have a vested interest in maintaining Jekyll even if they had to fork it to improve upon it.
- nickjj 8y ago
  md5 tagging at the Hugo level has been talked about since 2014 and it's still no where on the horizon. If SASS support still isn't out yet, who knows how long "later" is. > Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero. They are working hard on Jekyll 4.x and huge sites like Docker's documentation[0] use Jekyll. I'd still feel comfortable using it today. It really comes down to preference IMO. Jekyll is more than adequate to use for a blog or large site. If you like liquid's template engine and enjoy having the ability to write plugins in Ruby then it's a good match. [0]: https://github.com/docker/docker.github.io https://github.com/docker/docker.github.io
  - benatkin 8y ago
    If you have a CDN or Varnish, they can provide eTags, and you don't need an md5 in the URL, except to save the browser from doing a GET request and getting a 304 Not Modified. A few Not Modified requests served by a fast server is worth the tradeoff of not having to deal with an asset pipeline, or worse, overly aggressive caching, which is common in asset pipeline environments where the cache settings designed for md5 tagged assets inevitably get applied to non-tagged assets.
    - qw 8y ago
      That would cause issues when deploying new versions. Even if the CDN or Varnish serves an updated etag, the browsers could potentially keep using an older version from its cache. Not what you want when you just fixed important bugs. This has happened to me, even without aggressive caching. I suspect that even if you told the browser to revalidate on each request, you would end up in situations where the browser ignores it or is overruled by a corporate proxy. With a md5 in the URL, the browser would be forced to make a new request.
      - benatkin 8y ago
        I've seen that happen, but I've seen people reset their browser caches because of misconfigured aggressive caching much more often. IMO max-age=0, must-revalidate is a much better choice for the average website/blog owner. For complex apps, setting up the asset pipeline can be worth the tradeoff. But Hugo is hardly a lower tier static site generator for not supporting this.
- kipari 8y ago
  > which is essentially abandonware Could you please expand on this? This seems like something that requires a source.
- nicoburns 8y ago
  Oo, that will be awesome. I use hugo for my personal website, and currently run the node-sass cli separately.
- edem 8y ago
  The reasons to use hugo are negative. I only have cons to it.
benatkin 8y ago
Having few assets is better than having a fancy asset pipeline. https://www.gatsbyjs.org/ https://www.gatsbyjs.org/ supports code splitting and since it uses JavaScript, CSS generation libraries like styled-components, Glamourous, and JSS are available. That means only outputting the CSS and JS that are needed for the page. This is great for blogs where someone might only read one article. The Hugo community is working toward minimal assets too.
- nickjj 8y ago
  > Having few assets is better than having a fancy asset pipeline. It's not about a fancy asset pipeline. It's taking app.css and turning it into app.a5fec617.css so that you can configure your web server to cache it forever. It's important to do this for CSS, JS and all of your images and other assets. Each blog post of mine has a cover image and with 170 blog posts, that's 170 blog images that need to be md5 tagged. The asset pipeline (transforming SASS into CSS and minifying everything) is just a nice convenience. It's also nice to be able to just write {% asset foo.jpg %} and end up with <img src="images/foo.34fbc1e9.jpg" width="256" height="256" alt="foo" /> in the HTML. Never having to manually set a height/width or alt tag (unless I want to manually override it) saves a lot of time.
  - benatkin 8y ago
    Without md5 tagging but with a reasonably configured web server, the browser gets an eTag in the response headers to the first request to load that cover image, and sends it in the headers to the second request and gets a 304 Not Modified response with an empty body. The size of the cover image is completely moot when comparing a proper Hugo config vs a proper asset pipeline config.
    - qw 8y ago
      The main advantage of a hash is that browsers will download the new version of your CSS/JS on the next page view, while still caching it «forever» If the url stays the same, you never know what version your visitors will get. You might publish a new version, but the user would not see it due to browser caches or proxies.
kaushalmodi 8y ago
> rolling your own set up isn't feasible for that because for it to be done right I do cache-busting > hugo > minification using a simple bash wrapper script. Though, in the coming week, Hugo might natively start supporting the cache busting and minification.
Supermighty 8y ago
Minification, fingerprinting (md5 tagging), and similar features are being worked on for Hugo, and should be avail soon: https://twitter.com/GoHugoIO/status/1009923838346514433 https://twitter.com/GoHugoIO/status/1009923838346514433

Odenwaelder 8y ago

I absolutely love Hugo.

jaas 8y ago

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.

the_mitsuhiko 8y ago
I built the actix.rs website with hugo and while I generally like it it has some bizarre things that make development harder than necessary. Sometimes it randomly refuses to build pages that worked before, until you realize it has something to do with it now picking up other templates. But no error message. And that you can't shell out to helper scripts makes it very restricted in so many aspects. I wanted to extract source examples from other code and preprocess it and the only way I could make it work was some really ugly go template code and that didn't even let me implement everything I want since they are so restrictive :( I really wish one could shell out to an executable to fill the gaps. As an example this is how code snippets are included. Sadly we cannot remove leading spaces on the lines to remove extra indentation, so now the source files look ugly :( https://github.com/actix/actix-website/blob/master/layouts/shortcodes/include-example.html https://github.com/actix/actix-website/blob/master/layouts/s...
andy800 8y ago
Thank you! The LE site is terrific (as is LE itself). Because it is open-source, I essentially cloned it for a professional association. https://casinoanalytics.org https://casinoanalytics.org Credit to LE is on the FAQ page. Thanks again.
edem 8y ago
And it is full of implicit stuff, cryptic templates, and the whole thing is pretty unintuitive. You also cant write plugins for it. Jekyll has i18n support I dont know what you are talking about.

inputcoffee 8y ago

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. I don’t care about the speed differential. However if Hugo is actually easier somehow, well that would be tempting.

hnarayanan 8y ago
It is significantly easier to setup because (in typical Go style) only requires you to download and install a single fat binary. You do not need to do what you're otherwise doing with the likes of Jekyll which involve a significant Ruby environment alongside to function. I've been using it for over two years, and this is the thing I like most about it. In addition: * Yes, it's super fast. * It allows for clean layout of code with different layouts for different sections: e.g. https://github.com/hnarayanan/harishnarayanan.org https://github.com/hnarayanan/harishnarayanan.org * It's got a really friendly community for support.
nyolfen 8y ago
as someone with relatively rudimentary skills who tried and failed two or three times to get jekyll working on a throwaway vps, hugo is indeed very, very easy.

kchoudhu 8y ago

I feel like people spend more time migrating blogging engines than actually blogging.

dvlsg 8y ago
At least then you can blog about the blogging engine migration.
- confounded 8y ago
  I personally enjoy the grand tradition of nerds writing blogs only about how they set up a blog.
  - comboy 8y ago
    ham radio 2.0
  - kaushalmodi 8y ago
    I thought I would also end up just being one of those (I had a sort of setting-up the blog using Hugo post too). But lately my blogging on many other topics that I'm really passionate about has picked up. Writing in Org mode has really reduced the writing block for me. I'm so glad I switched from Octopress to Hugo about maybe 2 years back.
    - abricot 8y ago
      Have you at least blogged about using org-mode?
      - kaushalmodi 8y ago
        No, I got into developing an Emacs package that exports Org mode to Hugo-friendly Markdown - ox-hugo. Here's the package homepage created using Emacs/Org mode + ox-hugo + Hugo: https://ox-hugo.scripter.co/ https://ox-hugo.scripter.co/.
8y ago

pknopf 8y ago

I've used pretty much every product out there for static site generation, and I gave up. So I created [0] Statik. 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. [0] https://github.com/pauldotknopf/statik https://github.com/pauldotknopf/statik

superrad 8y ago
I believe there's a python static webpage generator that's been around for a while that already makes use of that name: https://github.com/thanethomson/statik https://github.com/thanethomson/statik
- pknopf 8y ago
  I realized that after I made it. And I don't care :)

slathrop 8y ago

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]. It will soon replace an aging version of the site[3] that was built with Sitecore CMS, .NET, and SQL Server. 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. 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]. 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. 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. 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. [1] https://app.rrpm.run/ https://app.rrpm.run/ [2] https://github.com/railroadpm/site https://github.com/railroadpm/site [3] http://www.railroadpm.org/ http://www.railroadpm.org/ [4] https://api.rrpm.run/reports/bnsf/all https://api.rrpm.run/reports/bnsf/all [5] https://discourse.gohugo.io/t/build-a-json-api-with-hugos-custom-output-formats/11523 https://discourse.gohugo.io/t/build-a-json-api-with-hugos-cu... [6] https://forestry.io/blog/build-a-json-api-with-hugo/ https://forestry.io/blog/build-a-json-api-with-hugo/

Avshalom 8y ago
Pretty sure you have conflated the abilities of the half dozen frontend frameworks you added (for simplicity) with the the backend you replaced. ".Net" (not actually a specific backend) and an rdbms are not in any significant way a friction against a REST api. Mean while the only noticable difference between the sites is the front end.
- slathrop 8y ago
  My comment above was intended to add some value and perspective on using Hugo in a real world business/industry/paying customer website scenario... something beyond a personal blog. So RE: the main discussion here about Jekyll and Hugo and static site generators (SSGs), I think that if you take a moment to consider the difference between the SSG/JAMstack approach vs. the traditional "build the response on every request" back-end approach (and I'm not picking on .NET and SQL Server there, I've developed many sites using them myself) you'll see that there are some huge differences[1]. I think the most important difference is that with SSGs and JAMstack, your back-end code only runs at build time, on free build server infrastructure. There is no runtime back-end code, and therefore you can operate these JAMstack sites, at scale, at zero or near-zero operating cost. In the case of my customer, I estimate I saved them $100K over the life of this new site. Of course, your use-case must align with this sort of architecture. Not every site can or should be totally re-generated when content is changed. And importantly for my customer, they did not have to sacrifice a nice, user-friendly content-management experience. I happen to be using Netlify CMS, but others like Contentful and Forestry are nice options too[2]. [1] https://youtu.be/uWTMEDEPw8c https://youtu.be/uWTMEDEPw8c [2] https://headlesscms.org/ https://headlesscms.org/

therealmarv 8y ago

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 open source headless CMS Strapi https://strapi.io https://strapi.io and Nuxt.js frontend. If anybody knows a python and flask based headless CMS let me know!

tomd 8y ago
Not Flask, but still Python: Wagtail - https://github.com/wagtail/wagtail https://github.com/wagtail/wagtail - is a popular headless CMS option. Michael Harrison from rice.edu / Openstax gave a great talk about this at last week's Wagtail Space: https://docs.google.com/presentation/d/1ZYMogOeXKCCmr7hDZnzx0euw2pD5VCwtv3a7zHB4FW0/ https://docs.google.com/presentation/d/1ZYMogOeXKCCmr7hDZnzx... https://www.youtube.com/watch?v=HZT14u6WwdY https://www.youtube.com/watch?v=HZT14u6WwdY
- therealmarv 8y ago
  big thanks. Actually I worked for Openstax (Connexions) in the past but I think I did not met Michael Harrison at my time :)) I will definitely give it a testrun!

woodruffw 8y ago

FWIW, I achieved something like live reloading in Jekyll using an additional config file. _config_local.yml: html_refresh: true html_refresh_rate: 5 Then, I appended the config via: jekyll serve --config _config.yml,_config_local.yml --force-polling And then did a check in my header include: {% if site.html_refresh %} <meta http-equiv="refresh" content="{{ site.html_refresh_rate }}"> {% endif %} You can find a working example in my blog's repo[1]. [1]: https://github.com/woodruffw/blog https://github.com/woodruffw/blog

baxtr 8y ago

We’re running our blog on Jekyll. Is there any good reason to migrate to Hugo? In the article I’ve found this comment: 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) 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...)?

Sir_Cmpwn 8y ago
I'm not sure you understand. That quote is not listing Hugo's limitations, but rather it's strengths compared to Jekyll.

joeblau 8y ago

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. 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. I'm still fixing some https issues with GitHub static site hosting, but it should be working soon. [1] - https://github.com/dvcs/gitdvcs.com https://github.com/dvcs/gitdvcs.com

smoser 8y ago

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. https://github.com/gohugoio/hugo/issues/1921 https://github.com/gohugoio/hugo/issues/1921

rammy1234 8y ago

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. https://www.rammy.in https://www.rammy.in

dguo 8y ago
Hey, just giving you a heads up that the www version of your site gives me an SSL error. https://rammy.in https://rammy.in works though.

sytse 8y ago

If you want to use Hugo integrated with source control please know that our GitLab pages had support for our and 25 other static site generators.

jobvandervoort 8y ago
To be more precise, we support any static site generator, as we will serve any static content that you make available. So you can even use GitLab pages to e.g. display and easily share test output, documentation, or anything else. See: https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/ https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-page...

sandGorgon 8y ago

The momentum around static site builders is around the react based builders like Gatsby. 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. 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.

akerl_ 8y ago
Why would I spend a huge amount of time writing JS for the front-end?
- sandGorgon 8y ago
  You have the choice to. If you use reactjs based frameworks, you get the same amount of upfront effort as Hugo. It's not harder. However build times are slower. But as your website complexity increases, you can leverage the reactjs ecosystem (both people and libraries). In Hugo, you get locked to their templating system. Which is nice...but very non standard and relatively non-Googleable.
gschier 8y ago
I went this way too. If your site has a dynamic/interactive frontend, Gatsby makes it super easy to build a static-but-interactive site. Another huge plus with Gatsby is that it uses React's server-side-rendering to ensure that the site is still seo-friendly. If you have more than a few snippets of JS on your site, Hugo comes up way short. It's great for simple things though.
slathrop 8y ago
I ended up with a hybrid approach where Hugo and Golang templates are only for building the data (TOML files) into the required JSON for a read-only REST API. The remainder of the solution is all JavaScript (in my case Vue and Nuxt instead of React and Next). I came very close to switching to Gatsby early on, and I am very curious to know how my project[1] would have gone with Gatsby instead of Hugo. I get the impression that for the data manipulation (avoiding complex Golang templates that generate HTML) and for build speed, Hugo takes it. Certainly if you are working in React the simplicity of a single framework is the way to go, as you did. I also kind of felt a little more weird about mixing Gatsby and React with my preferred front-end framework, Vue, than I did about having to combine Golang template logic in one layer (API) with JavaScript in another layer (App). [1] https://github.com/railroadpm/site https://github.com/railroadpm/site

RobertRoberts 8y ago

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

davemateer 8y ago

The recent livereload feature on Jekyll coupled with running Jekyll locally in Docker works well me. https://davemateer.com/jekyl/2018/01/25/Jekyll-and-Docker.html https://davemateer.com/jekyl/2018/01/25/Jekyll-and-Docker.ht...

mattlondon 8y ago

I really like Hugo and use it for one of my websites. It is refreshing to get such a fast website. 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. 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). TL;Dr - good but if you want to do more than CSS tweaks on an existing theme then you're in for a challenge.

jotaen 8y ago
I second this. I built my own template from scratch and even though my layout structure is quite simple it consumed a lot of time to find out how where to put files in order to make things happen. I agree that better documentation would have helped, but it would be also great if Hugo was more (explicitly) configurable instead of purely relying on conventions. (Once setup though, I continue to enjoy Hugo – it’s fast and mostly stays out of one’s way.)
eevilspock 8y ago
Matt and jotaen, email me if you want to try out some changes I've made to Hugo that make it simple and easy without losing any power.

deltron3030 8y ago

SSGs got competition from zero configuration build tools like Parcel. https://medium.com/@chesterhow/building-a-static-site-with-parcel-part-1-de5032c6bba7 https://medium.com/@chesterhow/building-a-static-site-with-p...

edem 8y ago

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.

cryptos 8y ago

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). But besides that Hugo is a feature rich, fast and easy to install tool.

otterpro 8y ago
I don't know if this is the same issue, but there is a workaround in https://github.com/gohugoio/hugo/issues/1778 https://github.com/gohugoio/hugo/issues/1778. The TOC had been driving me crazy, and I had just learned to live with it for now, but I think the workaround can address some of the issue.

otterpro 8y ago

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