About this blog site

This is an experimental blog site using Nancy Markdown Blog. This page describes how this site evolved and the technology used.

Gus Beare

UPDATE: 8th June 2015. I decided to remove Pjax and go back to simpler Disqus loading as described here:
Comments on demand.

The main reasons I took the decision are problems with Pjax loading and issues with Adsense.

I found from time to time in some browsers the page refreshed normally when it was supposed to be Pjax loading the content. I couldn't work out why. With Google Adsense I found it wasn't providing relevant ads and also not refreshing when new content was loaded. There are ways around this but I decided it was too much work.


I wanted a very simple blog system that would free me from proprietary systems such as Wordpress and databases such as SQL Server or MySQL.

But why not just use Wordpress?

Well, to start with what would I learn using Wordpress? I could learn PHP and I would learn Wordpress but to be honest, I really don't want to. I'd have to learn another theming engine and another framework before I could even change some simple stuff on the home page. In addition I am not keen on learning PHP. I am comfortable with C# and I like Razor and the combination of Nancy and Razor is very satisfying and sensible to use.

When I looked at Nancy.Markdown.Blog I liked the idea of using text files in Markdown format for my posts. This means I am not tied to any tool like Live Writer to write posts. I can write them anywhere and upload them from any device that has an FTP client. The Nancy Markdown Blog engine is very simple to set up and gives me total control over everything. I wanted complete control over the HTML and js and didn't want a CMS making those decisions for me and I didn't want to be all at sea when I came across a bug that was a showstopper for me.

So, this site is an experiment to see if a blog system like this works for me.

Single Page Applications

For some time I have been interested in the idea of Single Page Applications. I have used Visual Studio Lightswitch and built several applications using the Lightswitch client. I liked Lightswitch but found it wasn't ideal for my needs. It was great if you were starting from scratch with a completely new data structure but I ran into a lot of problems when I tried to connect it to existing data stores.

I liked Silverlight and I liked the interfaces that were possible with Lightswitch (LS) but it wasn't ideal to run inside other web applications because I found it difficult to skin to match the host application and the Silverlight load time was a negative for cients who wanted instant page loads.

With regards to SEO LS applications were useless because you could only ever have a single route. You could use url parameters but you can't have a proper SEO friendly url for different logical pages.

Feeling frustrated with LS I started looking at js frameworks and research js SPA's. The problem with those I looked at were all about url's. I bought the book Single Page Applications by Michael Mikowski and although it's a great book it immediately put me off trying to build an SPA using the methods it recommended. I didn't like all the nonsense related to state handling and I didn't like the idea of piles of my own js on the client.

I feel that js on the client should be kept to a minimum and that it should be mainstream libraries that are used where the quality of the code is tested by millions of users and that the browser is very likely to already contain a cached copy of that code. I simply don't trust my own skills in a difficult language that I find hard to debug on the browser. I also noticed that many of these libraries involve creating routes on the client. This didn't make sense at all. The server will be handling the GET and POST's from the client and therefore it makes sense to have routes defined there. Why then would it make sense to also have routes in the front end js code?

Since I like Nancy Fx very much and I like Visual Studio with the outstanding Re-sharper I wanted the back end for my SPA to be built using tools I like and can debug easily and properly and productively. Why then would I ditch all that in favour of a horrible front end debugging experience and messy code that breaks the DRY principle?


After some research and playing with frameworks such as Sammy and Senna I finally found Pjax. What really swung it for me was this post on how to use Pjax with Nancy.

I wanted to use Pjax because I could create an application that functioned like an SPA but I could still use Nancy and Razor views and the front end js would be minimal. As you'll see the pages on this site appear to load quite nicely and if you look at the timestamp in the top right hand corner there should be no update unless some content takes an unusual amount of time to load.

The drawback of this approach is SEO and this could be a deal breaker. Pjax will update the title tag for you but it does not currently update the meta tags when the content is loaded. This is not important if you are just inserting fragments into a static page. But if each bunch of content represents a blog post then ideally it needs at least a meta description. I am told that the clever chaps behind pjax are building a new version that supports meta tag updates but they give no indication when this will become available. In the meantime I will see how Google indexes what I have. If it doesn't work well I will turn off pjax so that each post is static and the meta tags are loaded in the views at the back end.

Nancy Markdown Blog


A nice bonus to using this approach is that it's easy to backup/version and restore everything. Removing a database from the equation makes for much simpler version control. I am using Subversion to version my code and also the blog posts which are contained in the project folder. This means that I have copies of everything on local devices and also the main repo at Cloudforge.


Without a database deployment is also much easier and quicker. If I want to move to a new host I only have to copy the published files over to the new provider. No worries about moving the database which can be a pain. These days I am beginning to regret some of the decisions I made in the past with projects that are now a problem to maintain. Keeping things simple should help down the line.