At one point I tried switching to Hugo. I ended up moving back because I liked Liquid more than Go templates, and I liked the Jekyll plugins and ecosystem.*
Later I became frustrated with some complicated Jekyll sites that took 20 seconds to generate, so I ported Liquid, Jekyll, and some of the plugins, to Go.† This ran about twenty times faster.††
So that's kind of an apples-to-apples performance comparison between Jekyll (in Ruby) and Jekyll-like (in Go).
These days all my sites are simple, and I think Jekyll may have gotten faster too, so I've moved back to the Ruby implementation.
---
* YMMV. Many people are very happy with Hugo. Moving back to Jekyll was just my personal journey, not something I can defend with facts or figures.
† To be honest, at least as important was that I was looking for a Go learning project.
†† Presumably because (1) Go is a compiled language, and (2) goroutines.
I tried Hugo a week ago and using the quickstart example I got some error I had no idea what it meant. Running an example from their github produced an empty page.
The theme selection is also weak in comparison. So all in all it is a complete non-starter.
Jekyll however I know will work and the number of themes to choose from is huge.
As I already had content with templates in liquid and custom plugins written in ruby, migrating to Hugo would definitely have taken longer than doing the initial proof-of-concept, and despite the performance, I am happier working with Jekyll than Hugo.
The Jekyll code base would need major refactoring to allow for the lazy evaluation when using `serve` (and it would break some plugins) and likewise for the parallel builds because this is done with `fork` (as Ruby doesn’t have proper concurrency with threads due to the global interpreter lock).
So rather than try to refactor Jekyll, it would probably be a better strategy to use my re-implementation as the basis for a Jekyll 4.0, I’d say it’s 95% feature compatible with Jekyll and only about 2,500 lines of code.
While writing it, I did want to reach out to the Jekyll maintainers to talk about this option, but it wasn’t clear to me how to actually get in touch with them (e.g. no jekyll-dev mailing list that I could find), and I didn’t want to open an issue about this.
While writing it, I did want to reach out to the Jekyll maintainers to talk about this option, but it wasn’t clear to me how to actually get in touch with them
Jekyll is also one of the most popular projects on GitHub, with more than 35,000 stars; it’s not hard to find: https://github.com/jekyll/jekyll
Proposing my code be used as the basis of Jekyll 4.0 would be a bit controversial and require a long discussion about pros and cons, a possible migration strategy for problematic plugins etc.
Call me old fashioned, but opening an issue on GitHub is just not my idea of getting in touch with the development team to discuss such things.
The project lead seems to be about ensuring the community thrives and #2 on that list is about documentation.
As alluded to in my grandparent, what I was looking for was a venue to submit my open-ended thoughts about how to transition Jekyll to parallel builds and lazy evaluation, which would spark a longer discussion about the feasibility of this (e.g. how will it affect existing plugins, would it be OK for some of them to break in 4.0, at least those relying on undocumented API, etc.).
Many open source projects have a mailing list only about development which is great for discussing such things, and that is what I was looking for, as sending an unsolicited email to the project lead (who is tasked with ensuring the community thrives) is just not the same thing as starting a discussion on a development mailing list.
This might come a little Off-Topic but I really like the idea of having a decent native macOS editor. Textmate gets so many things right when it comes to ease of use and making the developers life a bit easier.
Currently neither Sublime, Atom or VSCode are really native (at least when it comes to UI looking at you sublime).
What many people, myself included, are missing is some code intelligence. Textmate might simply enable lots of language smartness by implementing the Language Server Spec https://langserver.org
So all of a sudden Textmate could offer autocompletion, refactoring, go to definition for many languages with minimal effort. The language servers are there the editor author only needs to implement the spec one time and it can work for so many languages.
Great to see things moving forward in the Textmate domain.
I’m currently also planning to setup my site in Jekyll or Hugo or something. Apparently I want a blog with static site features.
Allan, your changes sound awesome but I srsly hope that it can get upstreamed to Jekyll in some way so the community won’t get divided by creating a popular second fork. The most valuable asset when it comes to Open Source software is imho the community around it.
I’d create a pull request and get discussion started this way.
