Hacker News Reader

Comment by swaggyBoatswain | Hacker News Reader

Stick with Jekyll, its robust, has support with github pages, most number of themes for a static site generator, and the benefits you get from Hugo for performance are very small

View on HN

What prevent Hugo from being supported by GitHub pages? I have never understood the "Jekyll integration" thing, you're just pushing static assets created by your static site generator to GitHub, so why would it be different from a generator to an other?

Github runs Jekyll for you, that's all integration there is. Meaning you do not have to push the generated files to update a Jekyll page hosted on there, only the source files.

Github is based on ruby, so is jekyll, so its a frictionless setup that's free.

You can use netlify but there's more setup to that than github imo.

with github you can also have as many sites as you want, little unknown fact just make 100 organizations and you have 100 sites. Content is open to anyone though. But the option is still nice to have

Hugo has support for GitLab Pages and GZ compression, with really nice CI tools and an open source downloadable server version, unlike GitHub:

https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gi...

https://about.gitlab.com/installation

IMO, GZ compression is really something that should be handled by your webserver and most do it easily. There is a jekyll-gzip plugin if for some reason you need it.

The content is static, and webservers like nginx support service gzip compressed equivalents if it finds it alongside the uncompressed ones. Might as well do that compression once rather than multiple times. If you're doing it just once, you can also realistically take the extra effort and use zopfli for further (albeit slower) compression.

Most of the major web server software caches the gzipped content. It only happens once.

Plus you can actually look at the files on the server without modification or piping them to gzip to check the files.

You can also elect not to gzip files smaller than MTU (1500 bytes) and stop wasting your and your client's time. Realistically it's often wasteful to gzip small files (below 5KB).

If you're worried about squeezing maximum compression out of your text files, then you're serving up too much stuff to clients anyway. You probably don't care about your users... just about your bloated page loading fast. Get rid of some ad garbage.

There are benefits to pre-compression:

https://theartofmachinery.com/2016/06/06/nginx_gzip_static.h...

That is what GitLab Pages expects, and because I can control my own pipeline with GitLab I am able to support multiple file formats that GitHub would not be able to support. It doesn't get any simpler than the example I provided.

I'll try and contain my derision towards serious conversations about hosting performance-sensitive content on GitHub/GitLab Pages. As explained in a separate comment, gziping _everything_ is wasting CPU.

If you just gzip from nginx, have content caching enabled (why don't you with static content?), and set a minimum size for gzipping, you have the best possible scenario and take a small hit on first requests of files until server-restart/cache-expiration.

> Stick with Jekyll, its robust, has support with github pages

Could you help me understand the value of this? It doesn't seem too hard for an SSG to provide documentation on what to put in a `.travis.yml` file.

There is 0 value. At some point there was some value, but not after the launch of services like Netlify.

In my experience, Netlify.com is 1000x better.

HTTPS, smooth integration with any SSG (including Hugo), any of the big git repos (GitHub, Gitlab, Bitbucket), great customer service, all for free.

What is the performance difference? All of them produce raw html and it's is served by static file servers right?

Performance during build, not serving the resulting files. I've seen people with really large Jekyll sites report build times of >40 minutes.

Reply on news.ycombinator.com