Kamishibai vs. Server-generated Javascript Responses

We’re writing some new capabilities for our Kamishibai.js Javascript library that powers our Ponzu conference system.

I haven’t documented Kamishibai.js, and at this point, it’s not even an independent library. Still, I just wanted to note a few things that crossed my mind recently.

Enough with the JavaScript Already!

A well written slide stack by Nicholas C. Zakas.

After consulting with several companies on performance related issues, it became clear that one of the biggest performance issues facing websites today is the sheer amount of JavaScript needed to power the page. The demand for more interactive and responsive applications has driven JavaScript usage through the roof. It’s quite common for large sites to end up with over 1 MB of JavaScript code on their page even after minification. But do today’s web applications really need that much JavaScript?

The answer in my opinion is no. Not nearly. Kamishibai.js is less than 50KB minified without HTML templates. It is smaller than the jquery.min.js file.

Server-generated JavaScript Responses

Written by David Heinemeir Hansson on the Signal v. Noise blog.

The essence of Server-generated JavaScript Responses (SJR) is as follows;

  1. Form is submitted via a XMLHttpRequest-powered form.
  2. Server creates or updates a model object.
  3. Server generates a JavaScript response that includes the updated HTML template for the model.
  4. Client evaluates the JavaScript returned by the server, which then updates the DOM.

I totally agree to this approach. In Kamishibai.js, we extend it in the following ways;

Instead of returning a Javascript response in 3, we usually send a simple HTML fragment. The Kamishibai.js library looks at our HTML fragment and searches it to see if any of the top level element ids are already present in the DOM. If so, then Kamishbai.js replaces the content of the DOM with the content in the HTML fragment. This allows us to do common DOM-replacements without any Javascript. If you want to add animations, you can do this declaratively through HTML data-attributes in the HTML fragment.

Another extension is the use of JSON. We totally agree that returning HTML is better than JSON if performance or readability of your code is your main issue. However in Kamishibai, we cache responses in localStorage which is very limited in capacity. Since JSON can be made many times more compact than HTML, we use JSON for the responses that we need to store a lot in localStorage.

In Kamishibai.js, we take a progressive approach to Javascript HTML templates. We start by returning HTML fragments. When we think we want to send a view with JSON, we write a Javascript HTML template and a JSON response for that view. Kamishibai.js can automatically determine if the response is an HTML fragment or JSON which should be used with a template. If it is JSON, then it summons the appropriate template and converted the JSON to an HTML fragment. That HTML fragment is further processed to be inserted into the DOM.

Summary

Kamishibai.js uses Javascript to generate pages, but the code is small and simple. We just expand on some concepts by those who eschew complex Javascript libraries, and provide the Javascript to make these approaches easier to follow.

I hope to write more on Kamishibai.js in the future.