4 ms·

Am I missing the benefit of a faster static site generator? Development phase speed?

by scosman 3y ago

jeeyoungk 3y ago
Jekyll is notoriously slow even for a very small website, unfortunately.
- arp242 3y ago
  It's really not that slow; my website builds in 0.8 seconds (121 pages) and OP's website builds in ~30 seconds (3,325 pages) – or rather, OP's website can be built in ~30 seconds (see my other comment: https://news.ycombinator.com/item?id=37277381 https://news.ycombinator.com/item?id=37277381) All of this is without cache, and with incremental builds disabled; it will obviously be faster with cache and incremental builds. I don't know where this "Jekyll is notoriously slow" comes from; maybe it was (very) old versions, or maybe it's some plugin people use, or maybe something else, but I've used Jekyll for a number of websites over the last ten years, and I never really had any performance issues. Certainly today, I think it's unfair to say that Jekyll is "slow". Yes, Go is faster, which should hardly surprise anyone, but for most purposes Jekyll should be more than fast enough, and you'll hardly notice the difference with something faster like Hugo or GoJekyll.
ladberg 3y ago
Jekyll is used by default for GitHub Pages sites, so I'm sure companies like GitHub would appreciate the savings from speedups like this.
- Simran-B 3y ago
  It would require full compatibility to be useful. I suppose most users of GitHub Pages don't actually use customization. Gojekyll could be used for building these, otherwise fall back to standard Jekyll. I believe GitHub Wikis are also rendered with Jekyll? Without customization capabilities on the user side, Gojekyll could be used here, too.
  - bandergirl 3y ago
    > I suppose most users of GitHub Pages don't actually use customization I don’t think you can actually load custom plugins, at least that wasn't the case the last time I looked. > I believe GitHub Wikis are also rendered with Jekyll? I don't see a reason to, they're just flat markdown documents, not a blog.
danogentili 3y ago
That and faster builds overall, especially with large projects. For example, the documentation of my MadelineProto project would take more than an hour to compile with Jekyll, compared to a few minutes with Gojekyll.
- arp242 3y ago
  An hour seems way too long; but I can confirm it's very slow. However, almost all of that is in this loop to generate the navigation: https://github.com/danog/MadelineProtoDocs/blob/master/docs/_layouts/default.html#L54-L69 https://github.com/danog/MadelineProtoDocs/blob/master/docs/... If I disable that your project builds in 30 seconds (no cache!) on my pretty old and not very fast i5-8350U, which is roughly what I'd expect for a project of this site. It will be even faster with cache, obviously. I didn't look too closely, but I'm reasonably sure that can fixed so the total build time will be 30-40 seconds without to much effort; it looks like it's just generating the same HTML every time, so just caching it on the first generation seems like the obvious way. And sure, Gojekyll is loads faster and more forgiving of these kind of inefficiencies, but "a few minutes" still seems pretty slow, especially considering even plain Jekyll can do it significantly faster.
  - danogentili 3y ago
    Neat, thanks for noticing, the theme is basically a slightly simplified version of https://github.com/just-the-docs/just-the-docs https://github.com/just-the-docs/just-the-docs, never suspected it was an issue with it, I'll take a look to see what can I fix!
    - arp242 3y ago
      I think GitHub Pages only supports a whitelist of plugins, so you might have some more difficulties solving it well without any plugins. I use Netlify for my site, which does support arbitrary plugins. One quick way to make it faster is to include that "_includes/nav.html" only in a nav.html, and then use an iframe to load that on every page, or something like that. Anyway, I'm not the first to notice this it seems, although even "twice as fast" would still be quite slow: https://github.com/just-the-docs/just-the-docs/issues/1323 https://github.com/just-the-docs/just-the-docs/issues/1323
midzer 3y ago
Some might argue Liquid templating language is easier for beginners.
- Simran-B 3y ago
  Some aspects of it certainly are, but it's also one of the more limited templating languages out of the box IMO, and there are several sharp edges especially in conjunction with Jekyll, where it requires you to do all the parsing of what gets passed to a custom tag or filter.
jmmv 3y ago
I have a blog with hundreds of posts. Jekyll would take multiple seconds to process any change (maybe even minutes for the initial build, cannot remember), so iterating over the final touches of a post was really painful. Hugo builds my whole site in less than 10 seconds and reloads individual post changes in milliseconds. It’s a game changer while previewing edits.
- BaseballPhysics 3y ago
  Yeah, but... surely, when you were iterating on a post, you were running Jekyll with --limit_posts or doing an incremental build? I agree, it's a nuisance that a full build can take a while (my own site, which has almost 600 posts plus a bunch of other random pages, takes at least 30 seconds for a full build, if memory serves), but it's hardly a dealbreaker.
  - jmmv 3y ago
    No because if I remember correctly, setting a limit on posts would break the build due to unresolved post cross-references.
    - BaseballPhysics 3y ago
      You mean links to other posts? So what? Check those in one final full build pass before publishing if it's a concern.
      - jmmv 3y ago
        Links to other posts, yes. The build just breaks if you link to a previous post that’s outside of the “limit posts” horizon.
        BaseballPhysics 3y ago
        Breaks? How? Jekyll doesn't enforce or validate links between posts. I know this because I build my site with --limit_posts all the time (it's literally part of my build pipeline due to the way I handle webmentions). Is there some plugin you were using that was blowing up?

Am I missing the benefit of a faster static site generator? Development phase speed?

jeeyoungk 3y ago

Jekyll is notoriously slow even for a very small website, unfortunately.

arp242 3y ago
It's really not that slow; my website builds in 0.8 seconds (121 pages) and OP's website builds in ~30 seconds (3,325 pages) – or rather, OP's website can be built in ~30 seconds (see my other comment: https://news.ycombinator.com/item?id=37277381 https://news.ycombinator.com/item?id=37277381) All of this is without cache, and with incremental builds disabled; it will obviously be faster with cache and incremental builds. I don't know where this "Jekyll is notoriously slow" comes from; maybe it was (very) old versions, or maybe it's some plugin people use, or maybe something else, but I've used Jekyll for a number of websites over the last ten years, and I never really had any performance issues. Certainly today, I think it's unfair to say that Jekyll is "slow". Yes, Go is faster, which should hardly surprise anyone, but for most purposes Jekyll should be more than fast enough, and you'll hardly notice the difference with something faster like Hugo or GoJekyll.

ladberg 3y ago

Jekyll is used by default for GitHub Pages sites, so I'm sure companies like GitHub would appreciate the savings from speedups like this.

Simran-B 3y ago
It would require full compatibility to be useful. I suppose most users of GitHub Pages don't actually use customization. Gojekyll could be used for building these, otherwise fall back to standard Jekyll. I believe GitHub Wikis are also rendered with Jekyll? Without customization capabilities on the user side, Gojekyll could be used here, too.
- bandergirl 3y ago
  > I suppose most users of GitHub Pages don't actually use customization I don’t think you can actually load custom plugins, at least that wasn't the case the last time I looked. > I believe GitHub Wikis are also rendered with Jekyll? I don't see a reason to, they're just flat markdown documents, not a blog.

danogentili 3y ago

That and faster builds overall, especially with large projects. For example, the documentation of my MadelineProto project would take more than an hour to compile with Jekyll, compared to a few minutes with Gojekyll.

arp242 3y ago
An hour seems way too long; but I can confirm it's very slow. However, almost all of that is in this loop to generate the navigation: https://github.com/danog/MadelineProtoDocs/blob/master/docs/_layouts/default.html#L54-L69 https://github.com/danog/MadelineProtoDocs/blob/master/docs/... If I disable that your project builds in 30 seconds (no cache!) on my pretty old and not very fast i5-8350U, which is roughly what I'd expect for a project of this site. It will be even faster with cache, obviously. I didn't look too closely, but I'm reasonably sure that can fixed so the total build time will be 30-40 seconds without to much effort; it looks like it's just generating the same HTML every time, so just caching it on the first generation seems like the obvious way. And sure, Gojekyll is loads faster and more forgiving of these kind of inefficiencies, but "a few minutes" still seems pretty slow, especially considering even plain Jekyll can do it significantly faster.
- danogentili 3y ago
  Neat, thanks for noticing, the theme is basically a slightly simplified version of https://github.com/just-the-docs/just-the-docs https://github.com/just-the-docs/just-the-docs, never suspected it was an issue with it, I'll take a look to see what can I fix!
  - arp242 3y ago
    I think GitHub Pages only supports a whitelist of plugins, so you might have some more difficulties solving it well without any plugins. I use Netlify for my site, which does support arbitrary plugins. One quick way to make it faster is to include that "_includes/nav.html" only in a nav.html, and then use an iframe to load that on every page, or something like that. Anyway, I'm not the first to notice this it seems, although even "twice as fast" would still be quite slow: https://github.com/just-the-docs/just-the-docs/issues/1323 https://github.com/just-the-docs/just-the-docs/issues/1323

midzer 3y ago

Some might argue Liquid templating language is easier for beginners.

Simran-B 3y ago
Some aspects of it certainly are, but it's also one of the more limited templating languages out of the box IMO, and there are several sharp edges especially in conjunction with Jekyll, where it requires you to do all the parsing of what gets passed to a custom tag or filter.

jmmv 3y ago

I have a blog with hundreds of posts. Jekyll would take multiple seconds to process any change (maybe even minutes for the initial build, cannot remember), so iterating over the final touches of a post was really painful. Hugo builds my whole site in less than 10 seconds and reloads individual post changes in milliseconds. It’s a game changer while previewing edits.

BaseballPhysics 3y ago
Yeah, but... surely, when you were iterating on a post, you were running Jekyll with --limit_posts or doing an incremental build? I agree, it's a nuisance that a full build can take a while (my own site, which has almost 600 posts plus a bunch of other random pages, takes at least 30 seconds for a full build, if memory serves), but it's hardly a dealbreaker.
- jmmv 3y ago
  No because if I remember correctly, setting a limit on posts would break the build due to unresolved post cross-references.
  - BaseballPhysics 3y ago
    You mean links to other posts? So what? Check those in one final full build pass before publishing if it's a concern.
    - jmmv 3y ago
      Links to other posts, yes. The build just breaks if you link to a previous post that’s outside of the “limit posts” horizon.
      - BaseballPhysics 3y ago
        Breaks? How? Jekyll doesn't enforce or validate links between posts. I know this because I build my site with --limit_posts all the time (it's literally part of my build pipeline due to the way I handle webmentions). Is there some plugin you were using that was blowing up?