This blog has been on four different platforms since starting in 2007: a custom blogging engine and then Movable Type on Nature Network 2007-2010, Wordpress on the PLOS Blogs Network 2010-2013, and the static blogging engine Jekyll hosted on Github Pages since 2013. It might be time for yet another blogging platform change.
The main reason to switch from Wordpress to Jekyll was the concept of a static site generator: write posts in markdown format, store them in a Github repository, and then have Jekyll automatically generate the HTML pages hosted on Github Pages. The main attraction was the blog posts in markdown format stored in git version control without the need of a database. Jekyll is the glue to make all this work, and I was able to customize Jekyll to my needs, e.g. by using Pandoc for the markdown to html conversion.
While this workflow still makes sense for this blog, there are a number of shortcomings:
- Jekyll needs to rebuild the entire site every time I publish a new post. While this isn’t much of a problem for the size of this blog, it doesn’t scale well for larger sites. And the process is more complex if you use custom jekyll plugins like this blog, as you can’t use the automatic Jekyll pipeline provided by Github (hint: use a Travis continous integration server to build the site)
- the tight integration between the code to generate the website and the content (Wordpress and other blogging engines have the same approach) is not always the best solution, e.g. when you want to want to generate the pages for something that is not a blog (e.g. a book).
What could we do instead?
The separation into API and frontend is of course old news. But for blogs this seems to still be a fairly new concept, in particular when combined with a backend using documents stored in git version control rather than in a database. Wordpress added a REST API Plugin in 2014, and the Ghost blogging framework (which uses a database backend) also seems to go into that general direction. Please ping me if you like the idea and want to contribute, or have implemented something like this already.
Using Markdown to author scholarly documents is an attractive alternative to the standard authoring tools Microsoft Word and LaTeX. The feeling shared by many is that Scholarly Markdown is 80% there, and that more effort is needed for the remaining 20% - moving markdown from a niche into the mainstream. What is mainly needed is building tools that connect the existing tools and ideas, resulting in one or more services attractive to a critical number of users. But maybe we also need to rethink the essential parts of Scholarly Markdown. In this post I propose that we expand the concept and define the Scholarly Markdown Bundle.