Move away from using Jekyll

[natebass]

Since we are currently redesigning the website, I want to consider moving away from Jekyll to another framework.

Some history

Jekyll is the static site generator, coded in Ruby, that is used by GitHub Pages. When the Code for Sacramento website was created in 2014, Ruby on Rails was more popular and GitHub Pages was kind of new and trendy.

Upsides of Jekyll

• Works by default with GitHub Pages.
  • An ideal use-case would be a repository with simple files (Pug or Markdown). These files could be updated by non-coders, and added on a regular basis to implement a blog (which we used to do from 2013-2016). A config file could then be used to add a theme.

Downsides of Jekyll

• Requires Ruby to develop locally. This requires learning a new package manager and virtual environment, which probably won't be used for any other Code for Sacramento project.
• When you add a lot of custom styling and embedded HTML, Pug/Markdown files begin to lose their simplicity.

The Code for Sacramento website has a little more functionality than just static pages. For example, it has a lot of custom styling and works with the GitHub API to dynamically display GitHub projects on the Projects page. I think this could justify using a framework like React.

Possible framework alternatives

• Gatsby
  • A static site generator using React.
• Eleventy
  • A simpler static site generator that closer resembles what we do with Jekyll today, except using NodeJS instead of Ruby.
  • Currently used by Open Budget Sac.
  • Next.js

Comparision of the popularity between different NodeJS static site generators https://jamstack.org/generators/.

[natebass]

I want to propose using Eleventy (NodeJS). We can keep a similar folder structure for static site generation. This should help preserve the git files and contributor history.

Using NodeJS will make it easier to develop locally. This will be relevant as we make a lot of changes in the near future. We want people to be able to spin up the code on their computer to contribute new pages, new CSS framework, and other UI/UX features.

A point contrasting React, from https://www.11ty.dev/docs/

Eleventy does not require that you use a JavaScript framework—that means zero client-side JavaScript by default across the board. We’re thinking long-term to opt-out of the framework rat race. The tool chain, modules, and components you use in your front end stack are decoupled from this tool. Work from a solid foundation of pre-rendered templates that suit your project’s progressive enhancement baseline requirements.

Any thoughts?

[natebass]

This change has been made by https://github.com/code4sac/codeforsacramento.org/pull/108