Dave đ§ąJekyll paved the way for an entire ecosystem of static site generators to flourish, but what do these new JavaScript SSGs offer over Jekyll? Letâs find out!
Whatâs wrong with Jekyll?
Hey! Whoa there, Iâm not about to start hating on Jekyll, here! Iâve got a real soft spot for that classic SSG - itâs what got me into the Jamstack in the first place. However, a lot has happened since that first commit back in October 2008, and the landscape has grown plenty enough to find out if there are greener pastures elsewhere for us.
If youâre someone with a long-standing Jekyll site somewhere, think of this article as the lightest of toe dips into the land of JavaScript based static site generators. Weâre going to take a look at some alternatives and the benefits we can gain from using JavaScript to build our Jamstack.
Variety in choice
Comparing Jekyll directly to JavaScript isnât a good idea, and very much âcomparing apples to orangesâ. Instead, letâs take a look at some of the wide variety of static site generators that are built on top of JavaScript:
Eleventy
Eleventy, or 11ty, is a wonderful SSG that has a lot in common with Jekyll. Liquid templating, Markdown source files, data files and other features are all here with many more for you to utilise. Iâve been using Eleventy a lot and Iâm really enjoying it, which I think is due to how similar it feels to Jekyll, while still giving me that vanilla JavaScript power.
Next.js
If youâve been tempted by React and want to use it to build out components, then maybe Next.js is more your bag for generating your site. Next.js is an open source project created by the team at Vercel, which is an ideal platform to host your Next.js site.
Gatsby.js
Gatsby is another static site generator based on React that has a large ecosystem of plugins and documentation. Iâd recommend checking out their official site to see if the features suit your project.
Nuxt.js
No, thatâs not a typo - itâs really called Nuxt.js. For those unfamiliar with the framework landscape, Vue is a JavaScript framework that sits in the same space as React. With Nuxt.js, you get all the features you need to create a Jamstack site, but with Vue as the core engine. Iâve used Nuxt.js, and despite my usage being brief, I had a good time writing out components and handling data.
Gridsome
Gridsome is another SSG with Vue at its core, but with an ecosystem more akin to Gatsby. Vue is quite an approachable framework: creating a component has similarities to writing regular HTML. Check out both the Vue docs and Gridsome docs to see if itâs a fit for you.
Scully
The SSGs listed above are some of the most popular out there, so I thought Iâd mention Scully to show something a bit different. Scully is based on Angular, a long standing JavaScript framework from Google. From what Iâve seen, Angular isnât as widely used as React or Vue, but if youâve had some good exposure to it on other projects, Scully might be just what youâre looking for.
Control over configuration
If youâve used Jekyll as much as I have, youâll know that it kind of has a strict configuration to it. Itâs original focus was blogging, and the method of adding a blog post meant creating files with particular names and putting them in particular folders. It was a similar case when adding a config and collections.
Screenshot for the official Jekyll documentation, on how you need to name your posts in a particular manner for them to work as expected
With these new JavaScript-based SSGs, you have much more of an open playing field to create your own structures, and configure them to your particular needs and preferences, for example: in an Eleventy project, you can name and organise your files however you wish, then configure Eleventy to express those files as a list of blog posts. Heck, you donât even have to use files for your blog postsâŚmore on that later.
Itâs JavaScript
Iâll admit, early in my career, I found JavaScript a bit daunting. It felt so exotic when comparing it to HTML and CSS syntax, which is probably why I warmed to tools like Jekyll to build out my web projects. However, JavaScript is an extremely ubiquitous language, with a vast array of resources surrounding it.
With that ubiquity comes a lot of people with pre-existing knowledge. If your team already knows a good amount of JavaScript, itâs going to be a big deciding factor for your next project.
You can write regular, or vanilla, JavaScript right alongside your framework specific code using any of the SSGs mentioned above, for example: I could be writing React components in a Next.js project and switch to ES6 JavaScript in the same file.
APIs and GraphQL at your fingertips
Okay, so this for me is the biggest game changer when going with a JavaScript based SSG over Jekyll. With Jekyll, your content has to be in a markdown file; yes, there are ways around this, but youâre going to have a bumpy ride doing it.
Publishing tools have come a long way and we should be utilising the best tools for the job - the best way to do that is with APIs. Rather than a markdown file, we can use services like Shopify for store products or TakeShape for our pages and posts, which can then be fed straight into our JavaScript SSG project. We can even use those sources all together, which is what the Jamstack is all about: bringing the best tools together to produce a content rich website.
Example of TakeShape's GraphQL query language
With TakeShape, not only can you produce your own custom CMS with itâs own API, but you can bring in multiple API resources to create a single endpoint to access all your data. Shopify, Contentful, Google Analytics and more can be used with Mesh - a single backend that can be accessed with a single GraphQL API.
GraphQL is a language for interacting with APIs and comes built into TakeShape. It can also be used with any of the static site generators mentioned above. Take a look at the Mesh feature page, as well as the official GraphQL docs for more information.
Build times
I find it hard to compare build times between SSGs, as they all perform differently with unique levels of complexity and content sizes. From what Iâve seen, my Jekyll projects range from 2 to 10 minutes for a build to complete. If youâre experiencing similar build times, I would consider checking out the alternatives listed higher up in this article and see what might fit your content structure.
Screenshot for from Sean's article, showing graphs they made for the article research
Sean C Davies does an excellent job of examining and comparing build times of the most commonly used SSGs in this research article. Youâll see that results show Jekyll does quite well in most cases, but Eleventy beats it for build times with large amounts of content - the other JavaScript SSGs do begin to catch up with the latter as the file count increases.
Again, itâs best to do a little research into these SSGs to see which will fit the content structure and feature set youâre aiming for. Which brings me nicely ontoâŚ
Use whatâs best for the job
Bet youâre thinking Iâve copâd out of this one, and pulled out the classic âIt dependsâ˘ď¸â for the article's conclusion. Thatâs certainly not the case; everything Iâve mentioned is valid and should be taken into consideration if youâre thinking of switching from Jekyll in an existing project, or if youâre wanting to switch up your typical stack.
Jekyll is a great tool, but there are limitations that prevent it from really excelling, especially in client projects. Itâs hard to use with an API, itsâ configuration is quite specific, and it can be hard to make it flex to different project types.
But letâs not leave it there! What do you think? Has this article made you consider Eleventy or Next.js more than before, or is Jekyll still pulling at your heartstrings? Tweet at @TakeShape on Twitter - weâd love to hear what you have to say đŚ
