> Anything to make static website builds faster is welcome
Genuine question, but why? My assumption here is that builds are infrequent and static sites gravitate towards being smaller in size, and that in most situations you’re building as an automated action following the addition/modification of a page. Does it matter if the build takes 1s vs 20s?
Even dynamically building during authoring, I rarely run into situations where ruby/js static site builders feel overly slow. Curious if my assumptions of how people are using these are wrong however so would love to hear your take.
I have 450 posts and about 300 more drafts with Jekyll.
In development it takes Jekyll 32 seconds[0] to do a full build and I've done my best to eliminate as many performance killing nested loops as possible. If I use --incremental it takes about 3 seconds, so my normal writing flow is to split my browser and code editor and I see real-time live reloaded feedback in 3 seconds.
It's pretty good, but some changes require a full build and waiting 30 seconds stinks. If I could snap my fingers and have a fully compatible Go solution that built it in 3 seconds all the time I'd switch without thinking.
Gojekyll isn't compatible with a few plugins I use and switching ~700 posts, a bunch of templates and a few custom plugins to Hugo isn't worth it for my use case.
On the other hand I'm locked into Jekyll 3.X because I can't get Jekyll-Assets to work with any other version so at some point I'll switch but I'm not looking forward to porting that many templates and posts. If it comes down to it I'd probably end up writing a custom tool to convert everything especially since I do custom'ish things with front matter like create a table of contents for each post. It'll require a bunch of string parsing.
[0]: This is on a 9 year old quad core i5 3.2ghz workstation with an SSD.
My team manages several static sites. They're each hundreds/thousands of pages in size. Here's why we like faster builds.
* Fast builds are way more pleasant during development. "Incremental" per-article builds help, but not in all scenarios. Nothing kills my motivation faster than having to wait 30 seconds to preview a fix.
* Fast builds help us avoid jams in our automated push-live systems. Sometimes we have many editors updating pages during a big event. You could consider many different trade-offs when deciding how to manage these queues. But a fast build time erases a lot of those conversations.
We use 11ty on most of our sites. We've found 11ty itself to be fairly performant. The slugs tend to be everything related to processing assets: JavaScript bundles, Sass builds, image manipulation, etc. By streamlining those activities, we can usually get a site build down to just a few seconds.
That said, "instant build" is the dream that animates the best conversations on our team, and we've started building our own static site generator. Our SSG can run both on the server and in the browser. We want our editors in our CMS to be able to get instant, true previews of the page they're editing. Then we want to be able to push single-article builds live, instead of always rebuilding the whole site. It's early days yet. Maybe you'll see it on a "Show HN" some day.
No, plugins are not supported in any meaningful way. With Jekyll I can write "_plugins/foo.rb" and put any code in there to add new Liquid template tags, new features, change behaviour, and even monkey-patch hard-coded core Jekyll code.[1] I can't do this with GoJekyll, because Go doesn't really provide a good mechanism for this kind of thing.
What it does have is a bunch of optional features that are typically provided by plugins in Jekyll[2], but this is a very different meaning of "plugins" that Jekyll has.
[1]: Whether you should be doing this is a different issue, but I would argue that for a static website builder it's fine, especially since you can just lock the Jekyll version with little downsides, and Jekyll doesn't change that often in the first place.
Context is everything. In the context of Jekyll, all of this is certainly a useful feature: this is not code that needs to be re-used or maintained in the same way as your Rails project has to be.
As always, engage your brain before doing anything and you don't need to use these features, but it gives you the tools to do "smart things" that Go simply can't. This, among other things, means that Jekyll will scale reasonably well with your website as your needs grow, without having to add features to Jekyll core, using your own fork of Jekyll, or switching to something completely different.
For example, I have a little plugin[1] to work around a bug[2] and to skip the hard-coded requirement to have a date in the filename.[3] Is this ugly? Yes. Is this fine to generate a relatively simple personal website? Also yes.
Yeah, in large projects that span a number of developers I agree with you. In a project that only I will ever touch? Like my personal blog? No way am I not going to reach for the most powerful featurea of a language. That sounds like exactly the right place to experiment with them.
> With Jekyll I can write "_plugins/foo.rb" and put any code in there to add new Liquid template tags
To be fair, Hugo's shortcodes are similar to this without requiring a plugin. And with render hooks and `.Scratch` to temporarily store information, it gets you a long way. It takes some time and experimentation to understand these abilities, however, and the documentation is not always helpful, to say the least.
Once there's feature parity, it'd be great to see more functionality added as first class features so that so many additional plugins aren't needed for seemingly common and basic needs. It's sad that Jekyll development pretty much all but stopped and any wanted features need to get shoehorned in via plugins.
But lack of plugin support is a pretty huge difference with the real Jekyll.