Note: This post was adapted from a slide presentation on That's why it's a bit heavy on bullet points.

The term "interactive static site" appears to be an oxymoron. In fact, they are all over the Web and have been for years. What's relatively new are developer-oriented site generation tools such as Jekyll; JavaScript MVC frameworks such as Backbone.js, Ember.js, and AngularJS; and Backend as a Service (BaaS) platforms such as Firebase and Parse.

Why static sites?

Static web sites are extremely stable, secure, economical, and fast. They can be great for SEO and analytics, and work best when the primary content is infrequently changed and document-oriented. This is true of most personal blogs, but also of many large sites, possibly even much e-commerce. A new version of is slated to be a massive static site, with content to be updated by non-technical users via Prose.

Indeed, the page you are reading was created and deployed with Octopress, a blog-specific wrapper for the slightly more generic Jekyll project. Jekyll is complex software, based on Ruby, Rake, and Git. Middleman may be even more complex than Jekyll, and reminds me of a command-line version of Rails. These are the heavyweight, mature solutions. For learning the concepts, check out something much simpler: Jeremy Ashkenas' delightfully readable Journo, a single-file, Node-based tool that deploys via rsync.

The problem: Some interactivity

We are talking about Sprinkles of JavaScript, not RIA: Most content is navigated through good old fashioned full-page reloads, but engaging the user requires scattered elements of interactive behavior and dynamic content.

The current solution: Third-party widgets and services

The ultimate example of a cross-site-loaded, service-backed widget may be Disqus, which is so popular for static blogs that it is a default in Octopress. On product and marketing sites, no doubt you have seen countless feedback and survey widgets. UserVoice is one example.

Pros - Third-party service

  • Easy to integrate
  • Mature, complete, and ready

Cons - Third-party service

  • Third-party branding
  • Difficult or impossible to customize
  • Vendor lock-in
  • Ugly ads or monthly fees

A better solution: Open-source widgets and Backend as a Service (BaaS)

With taglines like "Build apps fast without managing servers," there are already a number of commercial BaaS offerings.

Please let me know if somehow I missed including your favorite JavaScript-supporting BaaS!

Pros - Commercial BaaS

  • Generalized, flexible
  • Free tier is plenty for small stuff
  • Allow integration across your widgets
  • OAuth or custom auth
  • Fine-grained control over your data

Cons - Commercial BaaS

  • Not portable to alternative hosting
  • Obfuscated/closed source makes it hard to debug
  • Except Firebase, most are primarily for native mobile apps
  • VC-backing: acquisition or death?

The Dream: 100% FLOSS BaaS

Not much yet, (Ruby, iOS clients only) seems promising, especially since it has backing from Heroku.

Some others I found by looking around are BaasBox (Java), End.js (docs not in English), and (a work in progress).

Why I care about this stuff