Replace Jekyll with other markdown based site generator

[frankstrater]

Goal: reduce used languages in software stack of Media Suite

• [ ] Replace Ruby based Jekyll with another SSG
• [ ] Replace Siteleaf with another headless CMS

[frankstrater]

Headless CMS shortlist

Must be open source, Git based and support all site generators.

Under review:

• Tina (https://tina.io/)
• Netlify CMS / Decap (https://netlifycms.org)
• Strapi (https://strapi.io) Note: not Git based, but API driven

Discarded:

• CloudCannon (price)
• Forestry (EOL)
• SiteLeaf (Jekyll - price)
• Contentful (price)
• Ghost (limited - price)
• Prose (limited)
• Jekyll Admin (Jekyll - local only)
• Spinal (price)

Resources:

• https://jamstack.org/headless-cms/
• https://jekyllthemes.io/resources

[frankstrater]

Conclusion:

@gb-beng @jblom @KleinRana @roelandordelman

As Ruby is not one of the primary supported server-side programming/scripting languages at NISV (like Python, Java, PHP, NodeJS) there is no need for deep-diving and knowledge buildup for anything related to Ruby (although it's a beautiful language). As a build-tool for Jekyll SSG we will support it on occasion for rapid frontend development on Github Pages, but I strongly recommend to use Hugo (with Golang) for any SSG needs.

As far as Ruby installs (locally and/or server), just use what comes with the package manager. No need to fiddle around with rvm for Ruby versioning.

For the Media Suite website we'll continue to use Jekyll with Siteleaf as CMS for now. Jekyll itself might be upgraded, although it isn't needed and won't lead to any auto-magic improvements.

I extensively reviewed all other 3 headless CMS options mentioned above, but concluded (and agreed with Roeland) that we'll use Siteleaf, beacuse it's yearly price is cheaper than a migration to an alternative. Tina was promising, but eventually disappointing and more geared to ReactJS based framewroks.

I also recommend to use Strapi for any future website development with an external editor team with CMS needs (like the CLARIAH researchers) and forego any git/markdown based solutions unless your editors are internal collaborators/writers, like for the Labs website.