JPolite now provide SEO support

Initially, JPolite was designed as a starting point for web application building that all modules are supposed to be loaded via Ajax, which make most content invisible to search engines. Now that limitation has been broken with just a few lines of JS code. Just put an module into any of the existing containers, c1, c2 or c3, with an id in the following format {module_id#tab_id}, where the module id must be defined in “modules.js”, so as to enable reloading of the content.

Check out the demo here at: as well as the updated code at

BTW: a preliminary solution to integrate external Netvibes UWA widgets with iframes has been demonstrated as well.

From now on, my focus will be JPolite 2 that no major updates will be thrown into JPolite 1 except for bugs-fixes.

GTS – Grouped Tab Scroller

Mozilla Labs Design Challenge - Official Concept

Mozilla Labs Design Challenge - Official Concept

The GTS concept is my entry to the Mozilla Labs Design Challenge Summer’09 – Reinventing Tabs in the Browser. The use of tabs has become common place these days. But excessive use of too many tabs will inevitably cause user experience troubles. Therefore lots tab related plugins for Firefox emerge (251 so far), either as full featured replacement for the default tab controller, or minor improvement / customization to the default design.

Of course thumb view, coverflow view, vertical view as well as filtering, grouping, indexing, tagging, searching, sorting … can be added to tab navigation, but don’t forget the fundamental things: tab is NOT what we want in the end, it’s just a means to get us where we want. So the simpler the UI and the less time user spend on tab, the better!

GTS is a simple concept to help users organize tabs into groups (by domain, keyword, relevance …) while make them still accessible through the simple and familiar scroller control paradigm. It is not designed to handle 100s of tabs (so far) and I guess no solution can do that sound enough 🙂

Instead, GTS is just a tiny and elegent alternative for enjoyable tabbed browsing. For a live demo, please go to A brief video introduction can be found here:

Extreme testing of JavaScript delete operator on different browsers

When designing JPolite 2, I felt the need to do some memory management testing, especially about the delete operator. So I made a little piece of test page to illustrate the effect of delete on memory occupation of different browsers (as well as the performance of built-in JavaScript engines).

The approach is simple: add named attributes to an object X and then delete them. Benchmark the time spent, and memory footprint meanwhile. Three different test methods are used:

  • A. Add 1 attribute to X, then delete immediately  <– Repeat 1000s times
  • B. Bulk add 1000s of attributes, then bulk delete them
  • C. Bulk add 1000s of attributes, then delete X only

The tests were performed on Windows XP SP3, Intel Core Duo 2.16GHz CPU, 2GB RAM. IE7, FF3, Safari 4 and Chrome 2.0 were used in the test. No framework used at all, just plain simple JavaScript code.

Sample test code can be found here:

Some interesting results are gained that Safari 4 seems to be the fastest browser as Apple claimed, though Chrome 2 runs a little bit faster than Safari 4 in Test A. Chrome 2’s memory utilization seems to be the most efficient since it occupies least memory footprints. Firefox’sGC seems the best, which can always reclaim garbage in time. And IE7 is the slowest, whose performance drops dramatically when the number of attributes changes from 100K(~2.7s) to 1M(~200s). Funny thing is that, seems IE7 can eventually reclaim most of the garbage, where Safari & Chrome can not 🙂

Anyway, I’m in essence a front-end developer not a professional tester. Just went some extra miles on JS language and engine this time. However, I do hope my work can help you gain some more understanding of JavaScript and pros and cons of various browsers 😀


HATEOAS (Hypermedia as the engine of application state) is an essential but often overlooked / ignored constraint of the REST architectural style. Its importance is not that significant if you’re going to define some APIs for one-time use, i.e., the benefits will only gradually reveal over time. So I draft a simple case study of a sample online order management service to show why adopting HATEOAS is so important for minimizing maintenance cost and ensure backward compatibility.

JPolite 2 in the making …

I’m working on a new version of JPolite, name it JPolite 2 for the moment 🙂

It’ll carry lots changes in code structure as well as features and functions, like widget & theme support, login, layout persistence …

Moreover, Netvibes has gone through a upgrade which support multiple personal pages now. This is a great feature that I’m considering in JPolite 2 also …

Netvibes Upgrade

Netvibes Upgrade

So far, there are multiple objectives to accomplish, but the fundamental one will remain unchanged that I’ll keep the code base small, handy and easily extensible and customizable for anyone who like a Netvibes style UI for his own app 🙂

Just wait and see!