Last week I had a little discussion on Twitter about a great blog post by Zach Holman: Only 90s Web Developers Remember This (http://zachholman.com/posts/only-90s-developers/?). The post is not only fun to read, but also reminded me that it is now almost 20 years (1995) that I built my first website - of course using some of the techniques (the one pixel gif!, the
tag!) described in the post.
We started ScriptWeb back in 1995 as a central resource for scripting on the Mac (Applescript and Frontier). It was a nice collaborative effort and I was resposible for a directory of scripting additions (or osaxen), joining forces with MacScripter.net a few years later:
Since then I have built many other websites for fun and work, adapting to how technology changed over the years:
Since last June this blog is running on Github pages and the site is generated with Jekyll (http://jekyllrb.com/?). Jekyll works really well to build static websites such as this blog, but I am increasingly using it for more complex projects, e.g. for the online version of a book on Open Science (http://book.openingscience.org/?).
What I don’t know, and I am really interested to find out, is how well this scales to larger sites, specifically publisher websites that host thousands of scholarly journal articles - again content that is very text-heavy and doesn’t change that much. The potential benefits of replacing the paradigm of a database layer that holds all content with a paradigm that stores all content in files managed by git version control are clear: serving the content on the web becomes less complex, cheaper and faster. The tradeoff is of course that generating the static content becomes more complex and time-consuming, and it can become a challenge to mix the static content with dynamic content generated by servers as well as the user’s browser. For a now infamous example using this technology, look no further than Heathcare.gov (http://www.huffingtonpost.com/john-pavley/obamacare-website-problems_b_4057618.html?). I don’t know enough details to understand what went wrong, and it might have more to do with the scale of the project and the tight timeline to launch. For scholarly journal articles this might be a reasonable approach, as even when there is no longer a printed version of the journal, articles are still published on a specific date, and changing the content is a very formal process.