3 ms·

Closely related, I wish we had a better way of saying a library or product is now feature-complete. We use recent commit activity as a proxy of viability, but a

Closely related, I wish we had a better way of saying a library or product is now feature-complete. We use recent commit activity as a proxy of viability, but all of that churn could just as easily be an indication of immaturity. It's okay for tools to achieve their objectives and just live on as stable code with maintenance releases as needed. To my mind, Jekyll is feature-complete. The only changes I've needed to make to my Jekyll site are dealing with breakages from backwards-incompatible updates. I've been hosting with GitHub Pages for the past 12 years and I largely don't even have to think about it. It's nice.

jaredcwhite 5y ago
I get what you're saying, and for single-purposes libraries or other simple infrastructure, that totally makes sense. But Jekyll lives in a wider world of vital tools from Gatsby to Eleventy to Hugo to (fill in the blank of your favorite SSG), and if it can no longer serve its main audience relative to compelling alternatives, it's not feature-complete, it's obsolete.
- nirvdrum 5y ago
  I'd imagine Jekyll's main audience is GitHub Pages and it seems to be used quite widely there. I get what you're saying, but I don't think Jekyll needs to compete with every single site generator on every feature. Gatsby is a case where the whole concept is taken in a wildly different direction and that's fine. I can't use Gatsby the way I use Jekyll and so Gatsby isn't the tool for me. But, Jekyll takes Markdown and turns it into HTML really well and has done so for over a decade. It's really not that complicated a tool. I think there's probably two levels of discussion going on here. In very broad terms and with a generous scope of "we", we largely treat anything written in the last 15 years differently than anything that came before it. I don't know if it's because GitHub makes it so easy to see source or because recent languages have public repositories or something entirely different. But, no one looks at `bzip2` or `dig` and dismisses them as being obsolete because they don't have a hockey stick shape on the commit graph or because they don't serve multiple possible functions. To qrush's point, there has been a recent push to create "modern" implementations of system utilities and so we now have `ripgrep` and `bat` and maybe those new tools will reign supreme. But, I don't think that means `grep` or `cat` are dead and it's fantastic that they've worked reliably and consistently for so long (minus GNU vs BSD differences). So my lament, if you will, is software being declared dead just because activity on it has slowed down (or essentially ceased). I think another way to interpret that data is it's mature and stable. I think it's great that Jekyll is a reasonably stable utility that I can rely upon. I can even install it via `apt` now and not have to deal with the mess of maintaining a Ruby environment. I can push a commit to GitHub and have a high degree of certainty that my site will generate the way I expect and that can match what I see on my own local system. That level of maturity is something I'd like to see more software approach. In my experience, constantly chasing use cases often transforms a tool or library that was great at one thing into a tool that is okay at best at several things. Breaking compatibility is a good way to start annoying your supporters. Maybe Jekyll won't be adopted for greenfield projects and that'll lead to its obsolescence. I just think that's a premature proclamation. It has a massive installation base via GitHub Pages, so stability is likely the better lever to pull.
skrtskrt 5y ago
Even if the core project is feature complete and excellent, "death" can come from a lack of continued creation and maintenance of 3rd party integrations or plugins. Personally I found Jekyll plugins lacking and those that were good seemed pretty old/unmaintained. However I only moved to Hugo from Jekyll just because I didn't want to deal with Ruby gem installation and dependency management. I am not a Ruby dev by any means, I have enough dependency management misery from being a Python dev. Hugo installation is just a brew-installed or Go-installed CLI tool I never have to think about dependencies of, thanks to how great the Golang packaging/distribution situation is.
- nirvdrum 5y ago
  That's fair. Having to set up a Ruby installation to run a utility just isn't fun. Especially when the expectation is that you don't use the system-provided Ruby. You're supposed to go use a Ruby version manager and set all of that up. And that rough experience can contribute to its death, for sure. I just don't think "has few commits in the last month" is a great reason to declare a project as dead, especially one providing the backbone of GitHub Pages.
- ryantgtg 5y ago
  I recently went the other way - from hugo to jekyll - on a few sites. I find jekyll to be easier to install, modify, and maintain. And I recently rebuilt one of my Hugo sites the other day and got a notice about some function that is now deprecated and will break something soon. That’ll make the third time something like this has occurred with hugo in the last few years. Dun like it.
- pmontra 5y ago
  I'm using Jekyll (Ruby) in a docker container to manage the documentation of a Django project (Python). No need to deal with gems. Only docker pull and docker run. Most of the other developers don't know anything about Ruby. https://hub.docker.com/r/jekyll/jekyll/ https://hub.docker.com/r/jekyll/jekyll/
firecall 5y ago
Yes, it's not far off! I do use some simple plugins for things like Redirects and Sitemaps. But for many sites we build, what Jekyll does right now is just fine. It also works with CloudCannon. Who are expanding their supported SSGs. So if we shift our business, we'll likely just follow what ever SSG is blessed by them! :-)
RileyJames 5y ago
Couldn’t agree more. Have been using Jekyll for years for all manner of sites and the most beautiful feature is that I’ve barely changed anything. Even when I did recently update a few sites to new versions (mainly just because I was making some changes and figured why not) nothing broke.

jaredcwhite 5y ago

I get what you're saying, and for single-purposes libraries or other simple infrastructure, that totally makes sense. But Jekyll lives in a wider world of vital tools from Gatsby to Eleventy to Hugo to (fill in the blank of your favorite SSG), and if it can no longer serve its main audience relative to compelling alternatives, it's not feature-complete, it's obsolete.

nirvdrum 5y ago
I'd imagine Jekyll's main audience is GitHub Pages and it seems to be used quite widely there. I get what you're saying, but I don't think Jekyll needs to compete with every single site generator on every feature. Gatsby is a case where the whole concept is taken in a wildly different direction and that's fine. I can't use Gatsby the way I use Jekyll and so Gatsby isn't the tool for me. But, Jekyll takes Markdown and turns it into HTML really well and has done so for over a decade. It's really not that complicated a tool. I think there's probably two levels of discussion going on here. In very broad terms and with a generous scope of "we", we largely treat anything written in the last 15 years differently than anything that came before it. I don't know if it's because GitHub makes it so easy to see source or because recent languages have public repositories or something entirely different. But, no one looks at `bzip2` or `dig` and dismisses them as being obsolete because they don't have a hockey stick shape on the commit graph or because they don't serve multiple possible functions. To qrush's point, there has been a recent push to create "modern" implementations of system utilities and so we now have `ripgrep` and `bat` and maybe those new tools will reign supreme. But, I don't think that means `grep` or `cat` are dead and it's fantastic that they've worked reliably and consistently for so long (minus GNU vs BSD differences). So my lament, if you will, is software being declared dead just because activity on it has slowed down (or essentially ceased). I think another way to interpret that data is it's mature and stable. I think it's great that Jekyll is a reasonably stable utility that I can rely upon. I can even install it via `apt` now and not have to deal with the mess of maintaining a Ruby environment. I can push a commit to GitHub and have a high degree of certainty that my site will generate the way I expect and that can match what I see on my own local system. That level of maturity is something I'd like to see more software approach. In my experience, constantly chasing use cases often transforms a tool or library that was great at one thing into a tool that is okay at best at several things. Breaking compatibility is a good way to start annoying your supporters. Maybe Jekyll won't be adopted for greenfield projects and that'll lead to its obsolescence. I just think that's a premature proclamation. It has a massive installation base via GitHub Pages, so stability is likely the better lever to pull.

skrtskrt 5y ago

Even if the core project is feature complete and excellent, "death" can come from a lack of continued creation and maintenance of 3rd party integrations or plugins. Personally I found Jekyll plugins lacking and those that were good seemed pretty old/unmaintained. However I only moved to Hugo from Jekyll just because I didn't want to deal with Ruby gem installation and dependency management. I am not a Ruby dev by any means, I have enough dependency management misery from being a Python dev. Hugo installation is just a brew-installed or Go-installed CLI tool I never have to think about dependencies of, thanks to how great the Golang packaging/distribution situation is.

nirvdrum 5y ago
That's fair. Having to set up a Ruby installation to run a utility just isn't fun. Especially when the expectation is that you don't use the system-provided Ruby. You're supposed to go use a Ruby version manager and set all of that up. And that rough experience can contribute to its death, for sure. I just don't think "has few commits in the last month" is a great reason to declare a project as dead, especially one providing the backbone of GitHub Pages.
ryantgtg 5y ago
I recently went the other way - from hugo to jekyll - on a few sites. I find jekyll to be easier to install, modify, and maintain. And I recently rebuilt one of my Hugo sites the other day and got a notice about some function that is now deprecated and will break something soon. That’ll make the third time something like this has occurred with hugo in the last few years. Dun like it.
pmontra 5y ago
I'm using Jekyll (Ruby) in a docker container to manage the documentation of a Django project (Python). No need to deal with gems. Only docker pull and docker run. Most of the other developers don't know anything about Ruby. https://hub.docker.com/r/jekyll/jekyll/ https://hub.docker.com/r/jekyll/jekyll/

firecall 5y ago

Yes, it's not far off! I do use some simple plugins for things like Redirects and Sitemaps. But for many sites we build, what Jekyll does right now is just fine. It also works with CloudCannon. Who are expanding their supported SSGs. So if we shift our business, we'll likely just follow what ever SSG is blessed by them! :-)

RileyJames 5y ago

Couldn’t agree more. Have been using Jekyll for years for all manner of sites and the most beautiful feature is that I’ve barely changed anything. Even when I did recently update a few sites to new versions (mainly just because I was making some changes and figured why not) nothing broke.