Going Static - Why I don't need dynamic pages
This blog has now been upgraded to use simple static html pages instead of a CMS. Just a few days back, I had a good enough CMS in place for my blog powered by Google App Engine / Python 2.5. Having control over the code made it seriously customizable. But soon after I upgraded my blog last year, GAE made Python 2.7 as the latest.
I don’t post on my blog very frequently - and this upgrade meant more work for me to upgrate to 2.7, since GAE Python 2.5 is deprecated now (after a year). They didn’t just change the language, but a whole lot of toolset around it. Migration meant a lot of work at my end - Infact I found it was easier to re-write (with bit of re-use) my CMS in GAE Python 2.7 than trying to migrate from GAE Python 2.5
And what happens next? What happens when Python 3 and next stack becomes latest? It would end up being a lot of work again.
Apart from that, I never did enjoy writing online - be it Wordpress or my own CMS - I usually do so in Notepad/Notepad++/Gedit or oddly sometimes in Gmail(drafts). Porting plain text to online CMS meant a bit of HTML formatting work too.
I also did not like the fact that GAE does not give me an FTP like interface where I can download/upload individual files instead of the entire package - Github integration creates a workaround for me.
This blog doesn’t contain much dynamic stuff either. And having worked on creating custom static-site-generators earlier - I know almost nothing beats the performance of static pages.
There are many static site generators available - My search came down to a few that I felt comfortable about.
Widely used. Based on Ruby
Uses NodeJS. Written in CoffeeScript. Lots of functionality
Uses NodeJS and written in CoffeeScript. Limited compared to DocPad but flexible
DocPad was similar to Jekyll but written in CoffeeScript. Many features and many plugins available - However just like Jekyll, it dictates how you arrange your content. I loved its asset-pipelining feature to support multiple conversion formats. However I did not find a real usecase within my requirements.
Wintersmith was flexible in terms of arranging content. It does not have as many features as DocPad - however I found it fit to many of my requirements and got its flexiblity.
With both, DocPad and Wintersmith I would end up writing CoffeeScript at some point. If not, I would be doing workarounds like hacks around the framework.
NOTE: If you are not concerned about the static site-generator language / architecture / whatever… and, at times - redundant work, Jekyll is recommended - Its pretty easy to work with and stable. Also you can host your pages on Github - Very compelling option. Find out more here.
This tool is now published as Nirman**.
Some of the features at time of writing this:
Flexibility to arrange your site contents - the way you want it. All the stuff goes in “contents” directory.
Templating is similar to Jinja templates. Here we use Nunjucks templating
Additionaly, you can use your content files as your template - This helps avoid cases where you create a one line file just to point to another template file. This feature is optional.
Content metadata is available to your templates directly.
Markdown support via Showdown
You can simply add code here to create your own output.
Example: You want to create a page listing all the Categories in your content.
Front Matter - Configuration for a post/document can be placed as a front-matter at the top of the content file. You can add date, title, or anything that is supported as YAML. All this configuration is available to the Scope of the template
Code blocks within content ( <script type=“application/x-nirman-code” ).
Sometimes, you want a modified version of your data. For example: Metadata provides you the list of posts. However, in your content, you may require the post to be sorted/filtered by date/title/category/ (whatever) … Best is to leave this to you.
Simply create a code block within your content, get the items, and mention “scope.paginate(options)”. Then, in your content use the paged-data to render content. You require ApplyTemplateToContent = TRUE to use this feature.
Further… I am also looking to add stuff like page-breaks within content to paginate through long articles.
What about dynamic stuff?
I do not have any dynamic stuff anyways - Comments are on Disqus. And the contact-me form is used lesser and will be replaced with a static page.
But “dynamic” is not completely optional - there are few cases where I wish create forms. I might use Mongolab/Firebase - or something similar that I developed earlier - without having to create a dynamic site again.
This is the first post written after the change-to-static-site, using Notepad++. So far it has come out perfectly.
Keep Watching and Happy Coding
Update: After moving to static pages, I did experiment for a while with AppEngine and DigitalOcean for hosting. However I found maintaining my site with DigitalOcean was much easier. Additionally, I have found AppEngine having issues with serving static-content at certain times - this is since before I moved to static pages - I dont know why that happens. Overall, I am happy with DigitalOcean and it scales pretty well (with static pages) with moderate-to-heavy loads.