I just read this rather alarming post. Is the Jekyll project actually dead?
1 Like
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…
1 Like
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!
3 Likes
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.
2 Likes
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.
2 Likes
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!
4 Likes
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.
9 Likes
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.
3 Likes
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?
2 Likes
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.
1 Like
I’d rather be concerned if Jekyll is no longer Open Source. As much as Netlify and GitHub serve an easy deploy, let’s not forget, that web3 has just started, what will never do in its current state. But this is what I think Jekyll comes in, somehow at the low end, but with tremendous capabilities in regards simplicity, and this is exactly what those DApp guys currently trying to step over, unless separating content from presentation aka Katy DeCorah will be the game changer from a user point of view.
So if GH Pages became 100 times faster, who’d benefit? Is build time an issue, given that it runs once and results will be statically delivered? I’m sure “Jekyll in Go” would be delightful and fast, but would everybody (me included) easily create a plugin if needed, because its dead simple?
2 Likes
@datenimperator After I wrote that post I’ve come to realize GitHub Pages only takes 15 seconds to rebuild my website with 1100 posts and 4000 nested detail/summary tags. I have no speed complaints. Plus I’ve heard GO is filled with bugs. I’m happy Jogging alongside Jekyll.
wait a minute, 15 seconds??, no, wait, a minute! says nearly all of my sites, from 1-page-sites to 1000-page-sites. 
Jekyll is how i discovered Ruby, and i love it for that 
. If it does update to another language, it should be Crystal (once it interops with Ruby, of course)!
Jekyll feels like it’s surviving solely off ashmorali (poor soul 
), and i’m okay with that, but GitHub Pages sure feel dead! 
Those default themes are old and terrible, lol.
Yeah… i don’t even know where to go after Jekyll. It seems every programming language has their own cool new static-site-generator now… so many options! Probably best to just go with one’s favorite language, assuming one has the ability to do programming. But i doubt any of them will last as long as Jekyll, the turtle wins the race.
I personally have zero interest in Go, ew. Of the bajillion SSGs, i’d say Eleventy seems interesting, as you can choose your templating system, and as it seems simple yet flexible, especially about your data and file structure, although, i’m not a fan of JavaScript :/. And if python is your thing, there’s Pelican. Anyone can write a fast SSG, and many people seem to have, even with Rust(!), but as datenimperator said, who the heck wants to write plugins in Rust?? The name Rust says it all, lol. Ruby is much prettier. 
1 Like
From my point of view, whenever there are developments in HTML, SCSS or JavaScript, then there are new developments in Jekyll. Rather than googling Jekyll on how to use new localStorage functions for example, I would google Firefox or Chrome on how to use them.
I can’t think of a single Jekyll only new development. It would be interesting if you could post some examples.
Is Jekyll dead?
By the way, I still use and develop my site almost every day. If you ask me about it, I don’t care what people think about the future or if it is complete. Just make sure mine is still on the way to give the world better work and notes from my side.
You do not need to write Go to use Hugo. I created hugocodex.org with nice tips and tricks for first time Hugo users. Sure, the Go templating language is a bit inconvenient, but you can get used to it (I have).