> 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.
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.
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.
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.
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.
Could you please expand on this? This seems like something that requires a source.
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.
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.
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.
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.
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.