-
The fact that Hugo still doesn't play nicely with Tailwind 3 (2 years after T3 was released) is a real pain point.
I gave up on this ever being fixed quite a while back, but still check on the issue [1] every now and then. Seems like the only activity these days is bep bumping the milestone every month.
[1]: https://github.com/gohugoio/hugo/issues/8343
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
No, plugins are not supported in any meaningful way. With Jekyll I can write "_plugins/foo.rb" and put any code in there, and even monkey-patch core Jekyll code.[1] I can't do this with GoJekyll, because Go doesn't really provide a good mechanism for this.
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 it doesn't change that often in the first place.
[2]: A list of them: https://github.com/osteele/gojekyll/blob/main/docs/plugins.m...
-
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.
[1]: https://github.com/arp242/arp242.net/blob/master/_plugins/no...
[2]: https://github.com/jekyll/jekyll/issues/8707
[3]: https://stackoverflow.com/a/68287682/660921
-
just-the-docs
A modern, high customizable, responsive Jekyll theme for documentation with built-in search.
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
-
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.
-
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.
[1]: https://github.com/arp242/arp242.net/blob/master/_plugins/no...
[2]: https://github.com/jekyll/jekyll/issues/8707
[3]: https://stackoverflow.com/a/68287682/660921
-
another good one thats even smaller:
https://github.com/piranha/gostatic
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
This project uses another templating language, apparently based on Shopify.
(1) https://github.com/osteele/liquid
-
There is always https://github.com/traefik/yaegi - a Go interpreter written to make it easy to write plugins.
-
gutenberg
A fast static site generator in a single binary with everything built-in. https://www.getzola.org
I'm currently learning https://www.getzola.org/.
It's more manual than idy like but it's gonna be for a small personal and work website so I don't mind much.
It's super fast.
Doesn't seem to fit your use casr but still.
