I recently had an interesting experience trying to find a quick home for some client-side code that I wanted to share with someone. I just needed a single page and eventually landed on using GitHub Pages for the first time.
This is where I first ran into Jecky which is supported b Github as a means of producting static web sites from data and configuratin options. There are some interesting advantages to this approach, not the least of which is performance characteristics. In a world where web site performance is key to not losing visitors and higher conversion rates (assuming that applies to your content).
Tangentally, over the years, I’ve work on my resume in different ways and move toward dynamic generation from a JSON file sometime last year. This year, I ran into to project that was trying to standardize a JSON-based resume format and decided to align with that format, so I’ve had a lot of relevant data sitting in these files ready for subsequent editing and refinement.
The combination of blogging (albeit seldom in my case since I don’t often find the time) and the resume content’s relevance to this kind of web site, it occured to me to spend a little time trying the Jeckyl approach out. I started this work yesterday and have most of the content, layout, styles and components in place already.
What’s enchanting about this is that there is no need for a database (SQL or otherwise), no need to a CGI engine, be it PHP (in the case of WordPress), Java (JSP/Faces for example) or ASP (MVC or otherwise). The HTML file are generated at publish time and the site can be served up from entirely static content.
It’s true that there are some limitations to this approach, of course but none of those things are likely to get in the way in the forseeable future. Rich client code has become the norm, bypassing server-side solutions in many cases, other tham fetching and storing data, which can still be done via inexpensive cloud services, especially given the trend toward billling by the minute and scaling via functional approaches, such as lambda services.
What’s more, my recent adventures have taken me toward GraphQL as a better solution than REST services, making a separate NodeJS backend even more attractive but separate from any relevant content management.