Hacker News Reader

Comment by scosman | Hacker News Reader

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

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.

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.

No because if I remember correctly, setting a limit on posts would break the build due to unresolved post cross-references.

You mean links to other posts? So what? Check those in one final full build pass before publishing if it's a concern.

Links to other posts, yes. The build just breaks if you link to a previous post that’s outside of the “limit posts” horizon.

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?

It does. Do you use post_url?

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

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.

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

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

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)

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.

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.

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

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.

Neat, thanks for noticing, the theme is basically a slightly simplified version of 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!

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

Some might argue Liquid templating language is easier for beginners.

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.

Reply on news.ycombinator.com