When we decided we needed to redo the itnig website from scratch we managed to synthesize our needs in three words.
Fast, simple and reliable.
Is there anything faster, simpler and more reliable than static html? Writing a static html page in the dynamic world we live in was out of the question but we needed something that would allow us to do so in an easy way. That’s when we found Jekyll.
Jekyll lets you generate a static html site from dynamic components such as templates, partials, liquid code, markdown, etc.
Data structure
Data classes are structured in Collections, each collection being a folder where each instance is represented by a file. Each one of these files starts with what they call Front Matter a header where all the instance attributes are defined. This Front Matter is what allows relationships between classes, filtering, querying, etc.
Classes that don’t need an html page representation are stored using Data Files (a typical CSV file) instead of being represented by a file in a collection. In our case, we use them to store people working at our startups.
Data Sourcing
We could manually create a file in the _jobs collection every time we have a new job offer, or a new file in the _events collection every time we have a new event, but we love optimising our time, and we already update our job offers on Workable and our events on Meetup, so why not using their APIs? Well that’s exactly what we do. We periodically run a script that retrieves all jobs from Workable creating a file for each one that is then stored in the _jobs collection. We do the same for the upcoming events and we also use the Google Drive API to retrieve the latest version of the people CSV file.
Design
Once the structure is defined and some data is created you can start working on the design. You can define some properties and attributes on any file using the Front Matter, and obtain and play with your previously created data using Liquid (a templating engine created by Shopify), to finally show it using HTML.
Conclusions
After working on and maintaining a Jekyll site for a couple months I can say it meets our expectations, but there are a couple drawbacks you should take into account before jumping into adopting it.
The first one is precisely what makes it fast an reliable, that is, the lack of a backend. Before choosing Jekyll you’ll have to ask yourself if your project is simple enough to avoid user registration and complex class and DB modelling. If it is, go ahead.
The second one is the lack of a “backoffice” for non-tech people. Whenever we manually update the content of a file (adding for example the video url of an event once it is online) it needs to be synced with the repository using git, and deployed to the server where the site is hosted. This might look simple and clean from the developer’s perspective, but when the content has to be updated by non technical users, this can be a problem. You’ll have to make sure your content manager knows or is willing to learn git.