[HN Gopher] Gojekyll: A fast, partially compatible Go clone of J...
___________________________________________________________________
Gojekyll: A fast, partially compatible Go clone of Jekyll
Author : danogentili
Score : 71 points
Date : 2023-08-26 20:11 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nologic01 wrote:
| I guess the comparison with hugo is inevitable. It is a tough
| challenge, hugo is among the most popular go projects across
| _any_ domain.
|
| The table indicates both as being "fast" so that leaves jekyll
| compatibility as the primary differentiating factor.
|
| Not familiar with jekyll, so cant tell what sort of pool of users
| that compatibility promise applies to.
|
| But here is a tip: the weak point of hugo is its documentation
| ;-)
| monooso wrote:
| 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
| explodingcamera wrote:
| The latest reply in this GitHub issue links to documentation
| and a example repo showing that tailwind is supported though
| pjmlp wrote:
| Compiled language achieves high speedup versus an interpreted
| one, news at 11.
| [deleted]
| gkbrk wrote:
| Especially because it doesn't even have feature parity.
|
| Rewriting Jekyll in the original language with this feature set
| and compatibility would be faster as well.
| leksak wrote:
| Rust port in 3...2...
| nickserv wrote:
| Have had a good experience with Zola, written in Rust:
|
| https://www.getzola.org/
| Zezima wrote:
| Seconding Zola. Fantastic project. I built a site with >
| 200 pages (including media) in 90ms on an M1 MacBook Pro.
|
| There is no plug-in ecosystem unfortunately.
|
| Shortcodes are nice and a modest replacement. Missing any
| headless CMS integration naturally because it's
| statically typed and compiled.
| chucke wrote:
| So, no support for plugins. What's the upside then, considering
| that building static jekyll pages is a solved problem, even if it
| takes 500ms instead of 90ms?
| gkbrk wrote:
| Anything to make static website builds faster is welcome,
| especially with Jekyll compatibility.
|
| But lack of plugin support is a pretty huge difference with the
| real Jekyll.
| danogentili wrote:
| Plugins are actually supported, but they obviously have to be
| reimplemented in go.
|
| Gojekyll currently supports the github pages, sass, jemoji,
| sitemap, feed, redirect, seo tag and avatar plugins, among
| others, see
| https://github.com/osteele/gojekyll/blob/main/docs/plugins.m...
| for the full list.
| hanniabu wrote:
| 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.
| jmholla wrote:
| > Plugins are actually supported, but they obviously have to
| be reimplemented in go.
|
| What are your thoughts on developing a compatibility layer?
| arp242 wrote:
| 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.
|
| [2]: A list of them: https://github.com/osteele/gojekyll/blob
| /main/docs/plugins.m...
| meibo wrote:
| Having been on the other side of a messy ruby project,
| which had large parts of itself overridden by some addon
| scripts, maybe that's a good thing!
| arp242 wrote:
| 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/_pl
| ugins/no...
|
| [2]: https://github.com/jekyll/jekyll/issues/8707
|
| [3]: https://stackoverflow.com/a/68287682/660921
| devonkim wrote:
| I'm having some nightmare flashbacks to the "plugin"
| ecosystems of various PHP CMSes including WordPress
| Saphyel wrote:
| now do it in Rust!
| [deleted]
| passion__desire wrote:
| Go, Rust or Go Bust (sry)
| transfire wrote:
| Crystal would be a better target language.
| [deleted]
| waynesonfire wrote:
| Hahah
| scosman wrote:
| Am I missing the benefit of a faster static site generator?
| Development phase speed?
| midzer wrote:
| Some might argue Liquid templating language is easier for
| beginners.
| jeeyoungk wrote:
| Jekyll is notoriously slow even for a very small website,
| unfortunately.
| arp242 wrote:
| 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.
| ladberg wrote:
| Jekyll is used by default for GitHub Pages sites, so I'm sure
| companies like GitHub would appreciate the savings from
| speedups like this.
| danogentili wrote:
| 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 wrote:
| 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/m
| aster/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 wrote:
| 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!
| arp242 wrote:
| 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
| 38 wrote:
| another good one thats even smaller:
|
| https://github.com/piranha/gostatic
| arp242 wrote:
| The big upshot of Jekyll for me is that I can use Ruby plugins,
| and that Ruby allows me to do _Crazy Stuff(tm)_ with monkey-
| patching. This means I both have a "works out of the box
| experience", but that I can _also_ tweak and customize anything I
| want, or add new features in an "ad hoc" fashion when I need
| them - it's the best of both.
|
| This isn't possible with Go, because it's just not that kind of
| language; it's more or less impossible to have a plugin system
| similar to Jekyll.
|
| My dayjob is to write Go code and has been for almost 8 years, I
| think Go is a great language. But I don't think the language is a
| great fit for this kind of thing.
___________________________________________________________________
(page generated 2023-08-26 23:00 UTC)