Hacker News Reader

Comment by nickjj | Hacker News Reader

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.

View on HN

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.

Why do you say that Jekyll is abandonware?

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.

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

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.

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.

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.

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

As someone who follows Hugo development closely, I wouldn't be surprised if both md5 tagging (fingerprinting) and sass support is out in the next week :)

See the Hugo Discourse for more details.

Specifically: https://discourse.gohugo.io/t/coming-soon-sass-support-and-m...

> which is essentially abandonware

Could you please expand on this? This seems like something that requires a source.

Oo, that will be awesome. I use hugo for my personal website, and currently run the node-sass cli separately.

The reasons to use hugo are negative. I only have cons to it.

Having few assets is better than having a fancy asset pipeline. 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.

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

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.

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 generalize over all content dynamically, but they come at the cost of incurring more requests than expiration caching. I don't see how you could keep arguing here unless you didn't understand that trade-off.

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.

Minification, fingerprinting (md5 tagging), and similar features are being worked on for Hugo, and should be avail soon: https://twitter.com/GoHugoIO/status/1009923838346514433

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

Reply on news.ycombinator.com