Concerned about the future of Jekyll

Share
1

I manage several large websites, all of them written in static php. Only a few have actual blogs, most are just portfolio websites and a few e-commerce. Coming from Wordpress, I hated the constant security concerns associated with databases and poorly written plug-ins, etc.

Recently, I have been trying out various static site generators. Coming from a php background, I have tried Jigsaw and Katana but now I am trying out Jekyll. I must say, I really like the simplicity of Jekyll.

However, since my dev environment is Windows based, I hate that I am forced to use Ruby in order to run Jekyll. However, the simplicity of Jekyll keeps bringing me back to it.

That said, I am concerned about the future of Jekyll, as it doesn’t appear that anyone is interested in advancing it further. Should I continue with Jekyll or look at other SSGs that are actively maintained?

1 Like
2

Yes you have to install Ruby on Windows but then can use it for your projects. My understanding is the Windows Ruby installer streamlines this for you.

Ruby comes standard on mac but it is locked to an old version. Typically you’d use a package manager on mac or linux to install Ruby

Regarding Jekyll versus other tools - I do like the simplicity of Jekyll. You write content in markdown with some CSS and HTML and some JS if you need it and you can add plugins and themes.

Here is my basic Jekyll site.

A really minimal project has a config (optional actually but it sets your theme) and an index.md file (well actually optional if you use fallback to README.md). So yeah in GitHub Pages the leanest site you can make with Jekyll is exactly README.md and nothing else and dependencies and managed by the system.

Local development of course needs more set up.

Here is a project with an index and config

One for GH Actions using Jekyll 4

The other static generators out have a lot more boilerplate code, I feel like. And written in JS instead of md, so not friendly for non-devs who just want to write markdown and YAML.

There was a recent post here about Bridgetown as an offshoot of Jekyll also Ruby based and intended to be maintained and handle the modern web.

But it lacks the simplicity of Jekyll. From my research, Bridgetown needs Yarn and Webpack to run - which is overkill for the majority of my Jekyll sites which are fine as they are.

That Bridgetown post talks about Jekyll being down to one maintainer, which was news to me. I guess plenty of people use Jekyll but only a few are Ruby developers and so can’t easily maintain it. I have been working with Jekyll for a few years and have some Ruby experience and scratch my head when it comes to most of the Ruby related questions in this forum.

I would check out this post comparing WP, Wix and Jamstack

And check the Jamstack site itself. There are a bewildering amount of options in various languages.

Maybe this will help too

Gatsby has been a the popular choice I think in JS but I heard it is over engineered.

Next.js is similar in also being React-based. Actually the boilerplate seems low. But… your index page is written in JSX and not markdown.

If you use Hugo, you can download a binary and even add it in version control, so there are no Ruby or Go or JS dependencies. Hugo claims to be the fastest.

1 Like
3

Yes Jekyll is might better there.

No database. Just commits of files. And a history in GitHub so no need to backup a DB.

There will be good and bad plugins in any ecosystem, but WP has a reputation for bad ones from people copy and pasting StackOverflow code and also the danger of SQL and PHP vulnerabilities from bad plugins just doesn’t exist in Jekyll. Yes Jekyll and Ruby can still have vulnerabilities but they seem to get taken care of and also they only are used at built time so there is no danger of leaking passwords or user data or giving a hacker access to your server, like with PHP.

1 Like
4

I’m a windows user and from all the support issues for macs it seems like it is better suited to windows - not really - just seems to come across that way. I’ve never had much trouble with it. Hugo was appealing as the single binary was awesome.

I’ve been trying out all the latest and greatest - Hugo, Gatsby, Next - and for a simple static site Jekyll to me is the easiest to work with. Hugo was a little hard - but I eventually did everything there that I could in Jekyll but the speed wasn’t really much benefit for my small sites. Gatsby was very complicated - simple things like site variables were fairly complex. The image plugin was the coolest thing to me. Next was probably the most interesting to me - less complex than Gatsby.

I kinda like the fact that Jekyll is mature and not changing a whole lot - though I am not a cutting edge user so things like the sass gem being out of date don’t bother me much. I glanced at Bridgetown and since it is all about ruby of which I know nothing it doesn’t interest me. But I do like some of what they are doing. I’m just not interested if it isn’t JS based since I already know some of that.

It is funny to see gatsby and Next moving (?) to server side stuff - we went from a CMS to OMG how cool is a pure static site - to now going back to server side rendering - Next has an image plugin that seems similar to Gatsby but it is server side only. I don’t get that. Once it is available for static I will give it a closer look.

I still like Jekyll though. Course I have several years experience with it so that is a big advantage over all the others.

1 Like
5

On Windows, I build Jekyll websites using Windows Subsystem for Linux (WSL). I have a fully working Ubuntu/bash environment. Ruby is in its environment. I edit in VS Code or Atom on Windows, share the file system with WSL, and push to Github using either VS Code or bash.

The only caveat is that it’s somewhat important that you edit/build in the Windows filesystem rather than giving your Windows tools access to the emulated Linux filesystem. With the latest WSL announced a few months ago, you can even run GUI tools from within bash, but I haven’t tried that.

1 Like
6

More recent info on the issue, in this blogpost at “The Register” here…

1 Like
7

I’ve only started using Jekyll a couple of months ago. My first project was to migrate a fairly simple Wordpress site to Jekyll. I very much like the way that Jekyll and other static site generators work. Given the lack of clear maintenance future, I’m going to take a serious look at eleventy as a Jekyll alternative. From my initial look at it, the migration from Jekyll to eleventy should be very straightforward as it supports layouts, includes, as well as liquid templating (among other template languages).

1 Like
8

Hi Bob,
I tried Eleventy back in its early stages, before I ended up using Jekyll. It was still kind of clunky and the documentation left a lot to be desired and there wasn’t much available in the way of existing examples to learn from. I’m sure it has changed significantly since then. I would love to hear about your experience with Eleventy when you complete your next project.

I settled on Jekyll because ‘it just worked’ right out of the box and there are plenty of examples on Github to learn from. I would love to see the Jekyll community continue to thrive, but I too am concerned about the lack of interest in maintaining it.

1 Like
9

I wonder if the news of Jekyll’s lack of maintenance isn’t somewhat overblown. If you subscribe to its github activity you’ll see that there is activity several times a week, also here Pulse · jekyll/jekyll · GitHub it shows that in the last week 1 pull request was merged and 6 issues closed. Further:
• Jekyll will not suddenly stop working…
• I took a long look at Bridgetown as soapboxed here several times and find that the documentation speaks only to the in-crowd
• Comparision Jekyll ⇄ Eleventy, →another comparison

2 Likes
10

@michaelbach

Ah that is interesting.

Here is a frozen screenshot for a month view, as the data will change over time.

Screen Shot 2021-09-26 at 9.16.52 am
Screen Shot 2021-09-26 at 9.16.52 am2116×706 46.3 KB

So yes Jekyll does get work done on it. But without digging in, those might be large or tiny things. And they might be maintenance issues if there are two few contributors to add new features.

I’d also say that Jekyll is mature so a younger project is probably going to be unstable - like having a list of features and fixes on the roadmap and rapid development. I mean Jekyll is in version 4 and Hugo and 11ty are at 0.X and VuePress is at 1.X.

Yes Jekyll will continue to work.

But…

When we get to Ruby say 4, Jekyll but might never work with that.

Or if a vulnerability comes out in Jekyll or any of the many gems which might be lacking interest/maintenance, those just won’t get fixed.

Yes Jekyll is mature, so if it didn’t change for a few years I’d probably keep loving it for the things it already does now. But some people might be annoyed by certain bugs that never get fixes or that they want a feature that all the other static generators have added and therefore they choose to not use Jekyll.

Perl has been in decline since 2006. You can still install and run it but the community and package ecosystem is severely limited and it is hard to get Perl developers. So someone might avoid Jekyll in 2 years for now because it is hard to find developers who will build their site in Jekyll or who will answer their questions.

I tried out Bridgetown. It might be meant as a Jekyll replacement, but it also works differently. So that you have to be familar with the Ruby gems and NPM ecosystem and how to run the Yarn tasks. While Jekyll doesn’t assume you have Node installed or that you even have any JS to run, so you can focus on the content and of course still have to deal with Ruby gems.

I also want to throw in a link on Google searches in tech for these tools. Not perfect but goes give an idea of interest over time https://trends.google.com/trends/explore?cat=5&date=all&q=%2Fm%2F0_s0_f0,%2Fg%2F121bk8f1,Next.js,VuePress,%2Fg%2F11g0wgnhgc

2 Likes
11

Thank you, highly interesting! The trends look crushing :).
FWIW: Choosing (or switching) a CMS depends highly on the use case, of course. In my (probably rare) case, being over 70, having done webdev as a side interest for nearly 30 years, I need something that lives a little longer than me, especially my widely frequented illusions and my vision test FrACT. So I switched the latter to FOSS, and the former should be low maintenance and future-proof. In contrast: were I young and/or would want to live from web development, I’d certainly explore the bleeding edge more.

1 Like
12

I never used 11ty before but I figured out the basics and look around at some projects and tutorials and put this together. Some of the templates out there are very busy and have a ton of dependencies. This one just has one dependency.

1 Like
13

@michaelbach That link didn’t work for me, but I found it here:

https://cloudcannon.com/blog/eleventy-11ty-vs-jekyll

1 Like
14

It’s funny that you would say that because I felt the same way when I looked at the Docs. If Bridgetown is meant to appeal to a larger audience, it needs to have docs that will “explain it like we are 5 year-olds”

2 Likes
15

Keep in mind that since it’s a static site, your security vulnerabilities are cut down dramatically. So, it’s not as important to update, as say, WordPress. You might want to look into WSL or a virtual machine on windows as it makes it, in my opinion, a lot easier to run and install.

A comparison is WordPress is a like a Honda Civic. It’s super popular and easy to use, but you aren’t going to win a race with it… Jekyll is more like a Tesla. Sure, you need to find places to charge it, and it requires a bit more research (tell me about insurance!), and is a little different from normal cars, but it’s crazy fast and super dependable.

The cool features, at least I think, are from the Jekyll themes and plugins. They can make you site do crazy things. So, it’s not necessarily being hampered by the Jekyll core side of things, and theme and plugin development is extremely important.

2 Likes
16

Indeed. Jekyll vulnerabilities are at build time mostly vs runtime vulnerabilities for WP where someone can exploit a weakness to slow down the server or get a password.

So using a virtual machine or a container can help there, to avoid Jekyll having access to your entire machine (esp if you were installing and running Jekyll as root with sudo which is a bad idea anyway).

If you set a GitHub or some other token for Jekyll to use, of course that is available to Jekyll anyway

Jekyll might not get updates so much but if the community is interesting in making and updating plugins and themes then that will keep going.

Also the reason i hear for WordPress being famous for being a target for hackers is, beside it mean a large portion of the market, WP let’s you use custom plugins and these are often outdated or copy and pasted from StackOverflow without context. So similarly, the weakness of Jekyll might be down to how good a plugin is. But again not mattering so much unless you are connecting to say a database or API at build time. Or if your plugin generates some JS to run on the browser side.

1 Like
17

It seems that the static site generators are growing in importance since the last years. I started using WordPress in 2012, then I switched to Jekyll in 2019. A site made with a SSG is more secure, faster and chepear (in terms of hosting or maintenance) than a site made with a CMS like WordPress, where you need to keep the PHP version relatively updated, with updates that require a good web browser to customize the site, where you need to create a database, etc.; while in Jekyll you can do everything from the terminal, using markdown, yaml and csv files, where you do the backup using git, and doing the deployment with a bash script. However, the problem will be always the same: static is not dynamic, so the social management requires some vitamines (Disqus, etc).

Github uses it for its pages, so it’s a “safeguard”, let’s say. After all, the future of a technology is always the same: if people uses it, it will stay alive, if not, it will die. Then we better keep using it.

Actually I had doubts between Jekyll and Hugo. I came to Jekyll because it’s a more mature project, with less things to solve.

18

@JackieGable I’m back to follow up. Since writing back in September, I’ve started a new Eleventy project, converting (don’t laugh) an iWeb site that my wife had built back in the early 2000s when iWeb was an app from Apple for building websites. The code it generated was pretty nasty with tons of embedded styles. It’s still live at faustotasca.com. The Eleventy-based version is set to launch within the next couple of weeks.

But first a note: I am not a professional web dev. Since 2003, I’ve dabbled in web dev as a side-fascination, building sites with everything from MovableType, WordPress, SquareSpace, hand-coding, Meteor, Google Sites, Jekyll, and now Eleventy. Most of these were labors of love for friends and non-profits.

The docs are decent, not great, but quite usable. One of the things I don’t like about the docs is that they’re peppered with notes about which version each feature was introduced in. The 1.0 release is currently in beta.

Google search has become my very good friend and I’ve found numerous examples, tutorials, and starters for Eleventy. Here are just a few.

Eleventy supports a wide variety of template languages, including Liquid. I’ve decided to use Nunjucks (which is very similar to Liquid) as it seems to be what most Eleventy devs who write about it are using, and thus, there are more examples of it out there. Unlike Liquid, you cannot pass parameters using {% include %}. That said, Nunjucks has macros that provide similar functionality.

Now that I’m headlong into Eleventy, I’ve taken that Jekyll site that I built (which was a conversion from WordPress) and converted it to Eleventy (also soon to relaunch). This has been a bit of a slog as I had bought a premade Jekyll template. So there was a lot of code that I hadn’t written and was a challenge to understand and convert.

I ran into one other thing with the Jekyll project that I’m moving to Eleventy. Since I hadn’t worked on it in a couple of months, and I was deep into Eleventy learning, when I went back to work on it, “Jekyll crashed” and would not run it. It ultimately had to do with my Ruby setup. I don’t know what changed, but I was able to get it working again.

My gut sense from all of this is that I think there’s likely to be more future support for things based around node/npm, i.e., Eleventy, than around Ruby.