Live data from Hacker News

Migrating from Jekyll to Hugo

dannyguo.com

71–80 of 92 posts

Re: Migrating from Jekyll to Hugo

#71

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 complexit…

Thanks for sharing this. Fascinating!

I'm a big fan of serving content APIs as static assets like you are doing here. Especially good for content which changes infrequently (a few times a day rather than many times a minute).

Static site generators typically make it simple to publish a structured data view like a JSON or XML feed of content alongside content pages as HTML (such a bonus!), but it is interesting to see that you've separated the API generation entirely as a Hugo build. (presumably for compile speed?)

I work at Netlify and am something of a JAMstack enthusiast. I'd love to learn more about the experience of designing and building this. If you'd be interested in doing more of a write up, or just sharing any of the learnings from along the way, I'd love to chat.

(https://twitter.com/philhawksworth)

Re: Migrating from Jekyll to Hugo

#72

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 and Nuxt.js frontend. If anybody knows a python and flask based headless CM…

Not Flask, but still Python: 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/1ZYMogOeXKCCmr7hDZnzx...

https://www.youtube.com/watch?v=HZT14u6WwdY

Re: Migrating from Jekyll to Hugo

#73
post #40

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.

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

Re: Migrating from Jekyll to Hugo

#74

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 complexit…

You shouldn't rely on third-party fonts (some people like me block those) for your graphical design. This is how that page looks in my Chrome: https://i.imgur.com/y03EQBc.png (using uBlock Origin with Fanboy's Anti-thirdparty Fonts blocking list: https://www.fanboy.co.nz/fanboy-antifonts.txt). At least host those fonts yourself.

Meanwhile the old page works perfectly.

Re: Migrating from Jekyll to Hugo

#75
post #72

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 and Nuxt.js frontend. If anybody knows a python and flask based headless CM…

Not Flask, but still Python: 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/1ZYMogOeXKCCmr7hDZnzx... https://www.youtube.com/watch?v=HZT14u6WwdY

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!

Re: Migrating from Jekyll to Hugo

#76
post #63

Earlier quoted context omitted.

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.

Have you at least blogged about using org-mode?

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

Re: Migrating from Jekyll to Hugo

#77
post #74

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 complexit…

You shouldn't rely on third-party fonts (some people like me block those) for your graphical design. This is how that page looks in my Chrome: https://i.imgur.com/y03EQBc.png (using uBlock Origin with Fanboy's Anti-thirdparty Fonts blocking list: https://www.fanboy.co.nz/fanboy-antifonts.txt ). At least host those fonts yourself. Meanwhile the old page works perfectly.

I understand that you and some others may block 3rd party fonts, but the percentage of people that do this has to be tiny, no? I’d venture it’s around the amount that block all JavaScript.

Sure you should have your sites work without JavaScript and probably host all your fonts. I personally do that usually, but from a building standpoint, I’m assuming 3rd party fonts or forcing JavaScript for a normal site is going to be fine for more than 95% of your users.

Re: Migrating from Jekyll to Hugo

#78
post #31

Earlier quoted context omitted.

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 ignor…

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.

You can't shoot yourself in the foot with the md5 tagging approach. It completely solves cache invalidation in a simple way. That's why it's so popular.

When the content of your file changes you get a completely new file which has no cache headers associated to it. Then nginx caches the file forever, and when you make a change, a new file is created and the process repeats but if you don't make a change, then the same file is served from the user's local cache.

Re: Migrating from Jekyll to Hugo

#79

Earlier quoted context omitted.

Caching something forever just doesn't impress me at all, it did when I first heard about the rails pipeline, but what matters to me more is that it's cached through a proxy or CDN, and that eTags prevent large files containing the exact same bytes from being sent repeatedly to the same client.

It impresses me as a user though since ETag still incurs a round trip while "forever" expiration doesn't. There's a night and day difference between ETags and no HTTP request at all. You are likely complacent because you're always on a good connection, since you keep arguing in these comments (even farther down) as if conditional GET requests obsolete other forms of caching. The real benefit of ETags is that they gen…

Another thing to remember: browsers don't fire up unlimited requests, usually you have 6-8 pipes to get your assets through. Even simple if-modified-since will still take space in them, while "eternal caching" will leave them free, i.e. no request will be made.

Re: Migrating from Jekyll to Hugo

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

Post reply on HN