5 ms·

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 performa

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

jlpom 8y ago
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?
- detaro 8y ago
  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.
- Kagerjay 8y ago
  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
blocked_again 8y ago
What is the performance difference? All of them produce raw html and it's is served by static file servers right?
- detaro 8y ago
  Performance during build, not serving the resulting files. I've seen people with really large Jekyll sites report build times of >40 minutes.
techntoke 8y ago
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/.gitlab-ci.yml https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gi... https://about.gitlab.com/installation https://about.gitlab.com/installation
- busterarm 8y ago
  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.
  - Twirrim 8y ago
    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.
    - busterarm 8y ago
      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.
  - techntoke 8y ago
    There are benefits to pre-compression: https://theartofmachinery.com/2016/06/06/nginx_gzip_static.html 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.
epage 8y ago
> 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.
- kaushalmodi 8y ago
  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.

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

jlpom 8y ago

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?

detaro 8y ago
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.
Kagerjay 8y ago
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

blocked_again 8y ago

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

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

techntoke 8y ago

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/.gitlab-ci.yml https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gi... https://about.gitlab.com/installation https://about.gitlab.com/installation

busterarm 8y ago
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.
- Twirrim 8y ago
  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.
  - busterarm 8y ago
    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.
- techntoke 8y ago
  There are benefits to pre-compression: https://theartofmachinery.com/2016/06/06/nginx_gzip_static.html 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.

epage 8y ago

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

kaushalmodi 8y ago
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.