Tag Archives: Kamishibai

What is Kamishibai?

Below I describe the design goals of Kamishibai.

Kamishibai is a compositior

Kamishibai is a simple compositor, similar to the Quartz Compositor in Mac OS X. What this means can be illustrated by what Kamishibai does, and what it does not.

What Kamishibai does not.

  1. Kamishibai does not generate HTML from data through the use of templates.
  2. Kamishibai does not contain any business logic in the form of “Models”.
  3. Kamishibai is not a Javascript MVC framework.
  4. Kamishibai will never target native application development through phoneGap, etc. That’s not what Kamishibai is for.

What Kamishibai does.

  1. Kamishibai requests HTML fragments from the server and stores them in a local cache.
  2. Kamishibai replaces portions of the current DOM with HTML fragments from the server and displays them.
  3. Kamishibai intelligently places HTML fragments from the server into appropriate locations in the DOM based on attributes on the fragments.
  4. Kamishibai combines multiple fragments to generate a single DOM.
  5. Kamishibai local cache stores HTML fragments and also expires them.
  6. Kamishibai intelligently examines current network stability and uses the cached fragment or requests a new one from the server accordingly.
  7. Kamishibai interprets the URL and makes suitable Ajax requests to generate the page.
  8. Kamishibai intelligently discovers and fragments that are currently missing and requests them from the server.
  9. We think that explicit syncing sucks. Kamishibai will make syncing almost invisible to the end user.
  10. Kamishibai works offline.
  11. Kamishibai does not enforce a specific UI design and does not come with widgets. Designers are expected to be capable of coding their own widgets with HTML and CSS. This makes design extremely flexible so you can easily brand you website.

Why isn’t Kamishibai Javascript MVC?

  1. Ruby and Ruby-on-Rails are superb. There’s a huge amount of functionality that you will miss with current Javascript MVC frameworks.
  2. Javascript MVC frameworks typically require a lot of Javascript on the browser. This will make first load times for mobile devices extremely slow (seconds for Javascript MVC vs tenths of seconds for Kamishibai).
  3. Rendering HTML on mobile devices will always be slower than on powerful server hardware. Furthermore, pages rendered on the server will be cached for later use, making it even faster.
  4. If the server is slow, you can simply add more hardware. You can’t do that with client side libraries. You are always limited by whatever cheap and slow hardware the customer choses.
  5. Javascript MVC requires a steep learning curve. On the other hand, Kamishibai only requires a few extensions onto HTML, CSS. You don’t even need to learn Javascript to get started. You can easily convert preexisting websites, and even WordPress sites.

The need for speed (how Javascript slows things down)

Speed is a very important but often overlooked feature.

Regarding speed on mobile websites, there are several things to consider.

  • Web sites can be very fast to load.
  • Overuse of JavaScript can make mobile websites very slow, even if the resources are cached.
  • jQuery significantly slows down websites, just by being loaded and compiled.
  • Responsive web design is not the same as optimizing for mobile.

Discussion on the web

A detailed discussion about how jQuery can slow down websites was written by Martin Sutherland. I have confirmed this to be true, and this was the first reason I abandoned jQuery Mobile for use in Ponzu (there were many more important reasons, but this was the first show-stopper).

Arguments against responsive web design were put forward by Jason Zimdars of 37 Signals (Behind the speed: Basecamp mobile).

In Ponzu

In Ponzu, we ended up taking a similar route as Basecamp mobile by 37 Signals. Our setup is basically the same except that our Kamishibai Javascript library is much more complicated (but still much, much smaller than jQuery).

With Basecamp mobile, the resource sizes are as follows;

PC HTML:42.92KB, CSS: 515.79KB, JS: 273.80KB
Mobile HTML:16.90KB, CSS: 38.91KB, JS: 14.73KB

You can see that they cut down on the size of JS and CSS immensely. Since the browser has much less CSS and JS to parse and compile, the browser responds much faster after a reload (even when CSS and JS are cached).

With the MBSJ2012 Ponzu system, the sizes are the following;

PC HTML:12.20 + 13.61 + 3.09 = 28.90KB, CSS: 29.30KB, JS: 41.13KB
Mobile HTML:13.62 + 12.69 = 26.31KB, CSS: 18.19KB, JS: 40.96KB

Both Basecamp mobile and Ponzu keep the CSS and JS sizes very small.

Compare this to jQuery Mobile;

Mobile HTML: 2.73KB, CSS: 107.31KB, JS: 91.67 + 286.65 = 372.32 KB

The difference in JavaScript size is staggering.

Where you can see the difference

As mentioned in the articles that I linked to above, the difference in speed becomes apparent when the browser reads in the Javascript and parses it. Caching the response does not help.

When clicking on external links

Whenever browsers move to a new URL, they clear their memory. Therefore even common CSS and JS assets have to be reloaded and re-parsed. This can be prevented if the pages are loaded via Ajax. With Ajax, we keep using the same old CSS and Javascript.

jQuery Mobile mainly uses Ajax when links are clicked. Therefore, once you have loaded a jQuery Mobile page, you won’t notice slowness as long as you stay inside the same site. You will however notice slowness if you click a link to an external site (non-Ajax), and then come back. Coming back will require all the Javascript to be reloaded and re-parsed.

In other words, jQuery Mobile is OK if you stay if you never leave the site. It get’s terribly slow if you move in and out.

When you want to quickly look up something

When you are at the conference venue and you want to check up on you schedule, you want the page to show up fast. You don’t want to wait for seconds until your schedule shows up.

You want to first load to be fast. jQuery Mobile won’t provide that.

When you click on a link on twitter

The great thing about using the Web for the conference system as opposed to a native application, is that you can link to individual pages. For example, you could put a link on Twitter, telling the world how cool your presentation is and why they must come and see it. Anybody seeing that tweet could simply click on the link, and they will immediately see your abstract.

However with jQuery Mobile, it’s going to take a few seconds until the page shows up. Some people might decide that they don’t have enough time to wait and abort.


In Ponzu, we take speed very seriously. Without speed, many of the benefits of the system will be diminished. One of our strategies to achieve this goal, was to keep the size of our Javascript small. Other strategies including caching will be discussed later.

How many platforms do we have to support?

The simple question in the title can be reframed as “Do we want to exclude paying participants or distinguished speakers from accessing the conference program?”. Of course the answer is NO.

Although the percentage of smartphone users exceeding 50% of total mobile phone users in the United States, the number is much less in Japan. As of 2012, only about 30% of Japanese mobile phone users use a smartphone. Furthermore, demographics suggest that while younger to middle-aged people are more likely to own a smartphone, elder people, the people who tend to be distinguished professors, are not. Moreover young students are often admitted without charge. Therefore, if we were to calculate the total attendance fees from smartphone owning participants and to compare it with non-smartphone owners, we would probably find non-owners paying more.

Despite this, there is a tendency for conferences to provide native smartphone applications, which will not run on feature phones. Even when there is a website for PCs, it tends to be a very simple and rudimentary search system.

We think that this is a ridiculous situation. Our goal with MBSJ2012 and with the current Ponzu system is to support as many devices as possible, including the millenniums-old but always reliable medium; paper.

Our support strategy is as follows;

  1. PCs: The most ubiquitous digital device among conference participants is the PC. Every researcher has a PC to write presentations and journal articles. They will use their PCs to find out which presentations interest them, and which ones they will want to see.
  2. Smartphones: Smartphones are gaining in popularity and provide a huge amount of functionally. Many researchers will want to use smartphones to check the conference program.
  3. Feature phones: Although not as powerful as smartphones, feature phones are nonetheless capable of browsing websites. If an appropriate website is provided, feature phone users too can easily check the conference program.
  4. Tablets (iPad): Tablets are the ideal device for viewing conference programs on-site. They provide a wide screen while being totally usable standing. However, their popularity is still limited. The people who own tablets are a minority.
  5. Paper (PDF): PDFs are great for downloading and printing onto paper. If you do your homework and narrow down the presentations that you want to attend, then the amount of paper you have to bring is actually quite manageable.

Our commitment is to support all of the above media with the highest quality possible. Supporting five different media is a huge challenge, but was made possible by integrating all the platforms within Ponzu and Kamishibai.

To jQuery or not (jQuery vs. raw JavaScript)

In Kamishibai, we decided to not use jQuery. Instead, Kamishibai is written in native Javascript although we might use CoffeeScript in the near future.

The reasons for not using jQuery are as follows.

  1. Modern browsers have much better JavaScript support and many utility functions are provided natively. For example, we don’t need jQuery map functions anymore since they are provided natively.
  2. jQuery is big. Although this is rarely an issue with desktop browsers, rendering and compiling the jQuery library alone can take something like 2-300ms on a mobile device. This is not acceptable.
  3. A lot of code in jQuery is actually support for legacy browsers. We don’t need that baggage.
  4. The jQuery library is bloated with lots of legacy functions. I’m always confused by the multiple ways of attaching an event to an object, for example.
  5. CoffeeScript solves a lot of the verbosity issues with plain JavaScript. There is no need to use jQuery to clean up the syntax (unless you really dig the functional style).

Regarding item 2., Martin Sutherland has written up a great post titled “jQuery Mobile doubts” which completely covers my concerns about using jQuery in a mobile environment. (I don’t agree with his “Problem 2: Ajax navigation” though, which I will probably cover in a different post). Take a look for a more detailed analysis.

On the other hand, jQuery is fine if we have a fast network connection and are using a PC. jQuery has a lot of great libraries and we want to use them, especially if we need to do complex editing on the desktop.

We also use jQuery as a compatibility layer. jQuery is good for providing support for IE and we code some of our IE-specific polyfills using jQuery.

We never intend to load jQuery on a mobile device though.