Live data from Hacker News

Migrating from Jekyll to Hugo

dannyguo.com

31–40 of 92 posts

Re: Migrating from Jekyll to Hugo

#31
post #6

Earlier quoted context omitted.

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…

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

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.

Re: Migrating from Jekyll to Hugo

#32
post #17

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

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

Re: Migrating from Jekyll to Hugo

#34

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…

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.

Re: Migrating from Jekyll to Hugo

#35
post #31

Earlier quoted context omitted.

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

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.

Re: Migrating from Jekyll to Hugo

#36
post #30

Earlier quoted context omitted.

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.

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.

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.

Re: Migrating from Jekyll to Hugo

#37
post #17

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

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

I realized that after I made it.

And I don't care :)

Re: Migrating from Jekyll to Hugo

#38
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

Post reply on HN