Migrating from Jekyll to Hugo

Re:Migrating from Jekyll to Hugo by benatkin on Sunday June 24, 2018 @04:06PM (#17388150)

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.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by nickjj on Sunday June 24, 2018 @04:18PM (#17388210)

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

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by benatkin on Sunday June 24, 2018 @04:43PM (#17388293)

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.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by qw on Sunday June 24, 2018 @05:56PM (#17388589)

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.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by benatkin on Sunday June 24, 2018 @07:09PM (#17388867)

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.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by always_good on Sunday June 24, 2018 @08:40PM (#17389184)

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.

[ Parent | on HN ]

Re:Migrating from Jekyll to Hugo by rimliu on Monday June 25, 2018 @08:43AM (#17391919)

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.

[ Parent | on HN ]