9 ms·
Gojekyll: A fast, partially compatible Go clone of Jekyll
- pjmlp 3y agoCompiled language achieves high speedup versus an interpreted one, news at 11.
- gkbrk 3y agoEspecially 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 3y agoRust port in 3...2...
- nickserv 3y agoHave had a good experience with Zola, written in Rust: https://www.getzola.org/ https://www.getzola.org/
- Zezima 3y agoSeconding 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.
- thayne 3y agoMy problem with zola is you can only use markdown. So you can't right content in asciidoc or even plain html.
- deleted 3y ago[deleted]
- gkbrk 3y agoAnything 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 3y agoPlugins 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.md https://github.com/osteele/gojekyll/blob/main/docs/plugins.m... for the full list.
- jmholla 3y ago> Plugins are actually supported, but they obviously have to be reimplemented in go. What are your thoughts on developing a compatibility layer?
- arp242 3y agoNo, 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.md https://github.com/osteele/gojekyll/blob/main/docs/plugins.m...
- meibo 3y agoHaving 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!
- scosman 3y agoAm I missing the benefit of a faster static site generator? Development phase speed?
- jeeyoungk 3y agoJekyll is notoriously slow even for a very small website, unfortunately.
- arp242 3y agoIt'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 agoJekyll 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 agoIt 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.
- transfire 3y agoCrystal would be a better target language.
- deleted 3y ago[deleted]
- waynesonfire 3y agoHahah
- nologic01 3y agoI 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 3y agoThe 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 https://github.com/gohugoio/hugo/issues/8343
- explodingcamera 3y agoThe latest reply in this GitHub issue links to documentation and a example repo showing that tailwind is supported though
- fbdab103 3y agoStill annoys me to no end that Hugo chose RSS and it requires some song and dance to make ATOM formatted feeds.
- earthboundkid 3y agoThat issue should have been closed. This was resolved in Hugo 112. https://github.com/gohugoio/hugo/releases/tag/v0.112.0 https://github.com/gohugoio/hugo/releases/tag/v0.112.0
- monooso 3y agoPraise be. Thank you, I would never have seen that.
- 3y ago
- Saphyel 3y agonow do it in Rust!
- passion__desire 3y agoGo, Rust or Go Bust (sry)
- deleted 3y ago[deleted]
- arp242 3y agoThe big upshot of Jekyll for me is that I can use Ruby plugins, and that Ruby allows me to do Crazy Stuff™ 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.
- fbdab103 3y agoGenuinely curious, what kind of Crazy Stuff do you need for a static site generator? It strikes me as one of those technologies I want to be as boring as possible. I never want to debug why my content is not being rendered.
- arp242 3y agoIf you want "as boring as possible" and "never want to debug" then you probably shouldn't be using Jekyll in the first place; for simple boring use cases all you need is: for f in ./posts/*.md; do dst=site/$f:r.html cat head.html >$dst markdown $f >>$dst cat footer.html >>$dst done Or some variant of that, in your preferred language. There's loads of things you can do wrong in Jekyll even without any plugins, and this applies to most static site generators. Anyway, I have a list of plugins at [1]; some are as simple as "don't use leading 0 for dates but a space" so it looks nicer (IMHO) but still aligns well, and others are a bit more crazy such as "use Vim's :TOhtml for syntax highlighting because I think Rouge looks horrible". Stuff like "show all posts with the same tag as the current post" could be done in pure Liquid template too, but this is usually a lot more awkward and a lot slower, and convenience tags like {% warning %}Watch out!{% endwarning %} are completely unnecessary as such, but it's just convenient and nice. [1]: https://github.com/arp242/arp242.net/tree/master/_plugins https://github.com/arp242/arp242.net/tree/master/_plugins
- 3y ago
- chucke 3y agoSo, 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?
- 38 3y agoanother good one thats even smaller: https://github.com/piranha/gostatic https://github.com/piranha/gostatic
- tamimio 3y agoI probably tried most of these static sites generators, and so far the best feature-rich one is zola, and currently using it for my site and blog. https://www.getzola.org/ https://www.getzola.org/
- mikae1 3y ago> the best feature-rich one is zola I wouldn't call a generator that does not support dates in URLs feature-rich. Zola seems extremely opinionated. Dates in URLs are supported by nearly every SSG out there and it seems quite crucial if you want to migrate from one of those and keep your (cool) URLs.
- tamimio 3y ago> does not support dates in URLs feature-rich. If I’m getting what you mean correctly, Zola does support that, look for index transparency, add “transparent = true” to your _index.md, this post explains it for adding “blog” prefix [1] but you can do it with year prefix, then month prefix inside, your folders structure will be years, inside it months, inside it your posts, and your URL will be like this “site.com/year/month/title” (I did the same concept as you can see in these URLs [2]), that, or just write the date in your .md file as in “2023-May-some_title.md” like I did in my blog (empty blog, didn’t yet migrate but it explains it)[3] [1] https://peterbabic.dev/blog/setting-url-prefix-in-zola https://peterbabic.dev/blog/setting-url-prefix-in-zola [2] https://tamim.io/professional_projects/nerds-heavy-lift-drone-with-low-latency-command-and-control-over-cellular-5g-and-4k-video-stream-in-realtime/ https://tamim.io/professional_projects/nerds-heavy-lift-dron... https://tamim.io/resume/tech-stack/ https://tamim.io/resume/tech-stack/ [3] https://blog.tamim.io/2023-april-tbd-migrations https://blog.tamim.io/2023-april-tbd-migrations
- andreygrehov 3y agoThere is Hugo [1], what's the point? [1] https://gohugo.io/ https://gohugo.io/
- roguesupport 3y ago[dead]
- n8henrie 3y agoI could care less about faster, but I would sure love to switch from Jekyll to something that builds from a statically linked binary. I only put our blog posts a couple times per year, but it seems that the Jekyll dependencies move beneath my feet and break routinely. This is especially a pain because Jekyll and homebrew are the only ruby projects I work with frequently, and so I'm always at a loss for how to fix things -- rbenv, updating gemfiles, do I need to gem or rake or bundler something, architecture-specific problems with C dependencies, yuck. For now I just put everything into nix which seems ok, but I think I may make a third attempt at switching to Hugo soon, or maybe this, or maybe cobalt.
- mnstngr 3y agoTry using Jekyll via Docker. The whole stack is managed without mucking around the rest of the system, and trivial to update.
- etra0 3y agoI can relate to this. I blog sporadically, using different computers, and every time I had to pull the repo and get it to run, several things would break, resulting in a very painful dependency management process (I must admit that I lacked experience with ruby projects in general). After porting my blog to Hugo, having a single binary that can perform all tasks on all three operating systems I use (MacOS, Windows, and Linux) is a blessing, and now the blog builds incredibly quick.
- arp242 3y agoWith a Gemfile and Gemfile.lock you really don't need to do any of that. The only thing that you will need to do is "bundle install" once your Ruby version is updated, which can be prevented by not updating Ruby. I just locked the ruby version in my package manager as I only use Ruby for Jekyll. Other than that: if it works today, it should still work in a year, or 2 years, or 5 years.
- BaseballPhysics 3y ago> The only thing that you will need to do is "bundle install" once your Ruby version is updated, which can be prevented by not updating Ruby. I just locked the ruby version in my package manager as I only use Ruby for Jekyll. I'm not sure that's a good idea. While you might avoid unexpected updates to Ruby, you'll also avoid security patches for CVEs.
- mnstngr 3y agoThank you for creating this! I’ve been looking for an alternative to Jekyll locally, while also sticking to the Jekyll repo format to use with GitHub Pages. (Because the repo format is good enough, and trying to migrate to Hugo was a nightmare on each of the three attempts I made several months apart.)
- reustle 3y agoMaybe you can convince the dev team at gojek [0] to use it for some of their pages. A great on-brand case study :) [0] https://en.wikipedia.org/wiki/Gojek https://en.wikipedia.org/wiki/Gojek
- paradite 3y agoI'd say Sass support is less important now that we have stable support for css variables, and recently stable support for css nesting. https://caniuse.com/css-variables https://caniuse.com/css-variables https://caniuse.com/css-nesting https://caniuse.com/css-nesting
- mikae1 3y agoWait, is this a single binary? If so, that's the big deal. The only reason I left Jekyll for Hugo was that I could not maintain a working installation because of all dependencies and messy package management in Ruby. Pretty awesome that it's Bjørn, the Hugo developer that's behind Gojejyll.
- pcblues 3y agoJekyll provided me with a quick and dirty website publishing tool that works for what I want. I don't want it to change. It's slow to run, but I edit my templates and run a single bash script to update my site when I need to. I'm a data point for "I don't need a faster Jekyll, especially if compatibility breaks"