I just read this rather alarming post. Is the Jekyll project actually dead?
This is a better (less bias?) post about the whole thing actually. This makes me feel better about things.
Would still be nice to get some feedback from this community though…
I just started using Jekyll six weeks ago. I use it every day and I can assure you GitHub Pages (which uses Jekyll to build websites) is still alive and well.
Also your link is written by someone who wishes Jekyll was dead so his fork of Jekyll gains in popularity. It’s a morbid kind of link because justification for the hypothesis is a dead GitHub Jekyll Maintainer.
I could see an argument that Ruby (scripted language) is falling out of favor and Go (compiled language) will be taking it’s place. If GitHub Pages became 100 times faster by switching to Go I certainly would not complain!
The thing I am worried about is not Jekyll’s long term stability, that has been proved to be absolutely undoubted. I would love to have new features, active development, discussions, ideas… If I am looking for something Jekyll-related on the web, I seldom find posts dating back to less than three or four years ago.
To me (a proud Jekyll user since two years) Jekyll is still awesome and it is alive and kicking. Nevertheless it is its development which is stuck and worryingly without any future perspective.
If this ends up being actually true, this means that eventually Jekyll will die indeed: nobody would choose it over more appealing and feature-packed solutions, and the many people already using it will slowly but relentlessly switch to those other static site generators.
I have been using Jekyll since 2015. Jekyll is not dead, but it might be feature complete. The fact that Github is supporting Jekyll is very important. It makes Jekyll a very good choice. Jekyll is also quite fast.
Personally I have made the switch from Jekyll to Hugo, but Hugo is less evolved. Hugo is quite hard to understand, even for the people who are very much into it. Also, I have found that you are not able to use a directory structure when using the multilingual feature (alternative permalinks in the config). To me this is clearly a bug. The reaction to this on the forum was rather negative (which is another reason to choose for Jekyll):
I have never found inconsistent behaviour in Jekyll and I have built hundreds of websites with it. People have always been very helpful. There are SO many sources on Jekyll (including SO) and it is used on a lot of websites. Although I like Hugo for its speed, there is no clear reason NOT to use Jekyll.
I suppose that begs the question, why change to Hugo then?
Was it technical curiosity? Or did you just fancy a change?
I’ve been running some tests on various static hosts over the last week or so (Netlify, Vercel, GH Pages etc) with Jekyll, Hugo and 11ty. Jekyll was the easiest to setup, followed closely by 11ty, but i had lots of issues with getting 11ty to build on a number of hosts.
Hugo was just a nightmare to get the site setup, but once it was, the hosts were all fine. Hugo and 11ty weren’t that much quicker to build either.
The points you raise above, plus my testing, I don’t think ill be leaving Jekyll any time soon.
I have two reasons to choose for Hugo:
- build speed at very large websites (a factor 10)
- the option to process images (scale, crop, etc)
To me the first one is very important. I created a Hugo specific CMS that can deploy a website in under a second (including the build process). The second one is also very important, as I advertise my websites to be instantly loading. That requires a PERFECT optimization of images. Hugo is able to provide that without (expensive) third party tools.
However, there are a lot of reasons NOT to choose for Hugo:
- the complexity of Hugo
- Hugo’s strange scope (filepaths are not considered properly, while AMP pages are)
- Go templating (hard to read and write)
- the need for a build process (Github Pages builds Jekyll natively)
- the fact that Hugo is on 0.something, which allows for breaking changes
- the developer community being smaller
People who use Jekyll generally build faster websites:
Jekyll is awesome!
I’m a huge fan of Jekyll—have been for 3+ years—and also a Rubyist. I plan on migrating my personal site from Jekyll to Bridgetown because Ruby’s my jam and I want to try something different, but that doesn’t mean I’ve given up on Jekyll.
I like to refer to Jekyll as “the granddaddy of static site generators.” I encourage new developers to use Jekyll and GitHub Pages to create their portfolio websites because it’s such a great pairing for anyone at the introductory level—or any level for that matter!
As for Jekyll being considered dead, we have an entire community here on Jekyll Talk. If people are truly bothered by the prospect of this SSG becoming stagnant, they should start picking up issues and becoming regular contributors. Contact Ashwin Maroli and tell them you want to become a maintainer. It’s not easy keeping up with an open-source project and a codebase a large a Jekyll has got to be crazy! That’s definitely not a one-person job.
Open source is awesome and can lead to some great opportunities so if you’re thinking about it, just go for it! Reach out if you have questions about being a project maintainer (I’m on the Ruby for Good core team and our site is a Jekyll site) or open source in general and I’d be glad to chat about it.
If there’s one thing that really puts the future of Jekyll as a “live” project in doubt as far as I’m concerned, it’s the fact that GitHub Pages—the primary, easy platform for Jekyll deployment—apparently will never be updated to use Jekyll 4.0. When most users don’t upgrade, projects tend to die. The unavailability of complete documentation of the features in the versions of Jekyll, Liquid, etc. used by GitHub Pages is another problem that I think threatens the project’s liveness. It’s a very strange dynamic.
Sites like Netlify and Vercel are just as simple (if not more so) and support 4.x, so maybe it’s worth flipping over to one of them as a host?
Great suggestions, for me (maybe). That doesn’t change the fact that GitHub Pages has the preponderance of userbase and momentum.
Not sure if you saw this post on the GitHub blog:
in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.
Not sure how this differs from today where you can configure a GitHub action yourself to build your repo with the latest version of Jekyll (or any static site gen), but if it makes things easier that would be a win.
I would guess the key difference is:
without having to push the build output to a special branch of the repository.
which is what a user-configured GitHub action would currently have to do, I think.