JavaScript showdown: Fat client versus thin client

Alastair Aitken 20 May 2013 0




Flares had been passé for a number of years but, where I went to school, fashion required any number of years to percolate down from the avant garde to the 11 year old school boy. In my class year, being attired in a pair of bell-bottomed pantaloons carried the levy of social stigma; one friend of mine was defined by the trousers that his mother, unaware of the socially defining trends that had swept her son’s school, had purchased for him. The very name of his mother’s fashion-faux-pas-by-proxy became a nickname that he would carry throughout his school years and beyond.

Wide-bottomed pants once again became de rigueur as the wheel of fashion turned and I’ll admit that I found it difficult to discard the drainpipes which had helped me to avoid pariah status in my formative years. My solution was a bodge: trousers that were neither wide nor narrow. Unbeknownst to me at the time, they had the unfortunate appearance of slacks, something which no young man should be encountering before middle age.

And so it is that I find my head easily turned by pretty much every new piece of technology and, in particular, any fashionable young software framework that happens by. Subconsciously I never want to be caught, metaphorically, wearing a pair of slacks.

So there I was, having got to grips with Backbone.js with all its client-side capabilities when along came Twitter telling me that client-side rendering is not performant. Was I now behind the curve, wearing my Backbone.js flares alongside Twitter’s sparrow legs?

When I started in web development, content was always created on the server-side. JavaScript was crap and it seemed that industry rivalries would ensure that it remained so. Inevitably the capabilities of browsers improved and libraries such as jQuery helped to insulate the developer from the differences between browsers, allowing concentration on the creation of functionally-rich JavaScript applications that could effectively create content on the client.

But putting all that extra functionality on the client-side comes at a computational cost, potentially lengthening the all-important time between requesting a URL and seeing the results. Web users are an impatient bunch and every second that passes risks losing users.

Essentially the dilemma Twitter was addressing is whether to render content server-side or on the client. It’s a question that almost defines network technology: thin client or fat client? A thin client can be a web browser or a command line terminal, a fat client can be a networked application with greater computational powers. Processing has to take place somewhere between the source and the end user, and that balance of where it takes place is like a sliding scale: more processing on the server means less work for the client but the less that the client does, makes for a less-rich user experience.

But Twitter’s use case is fairly unique; if you visit Twitter and don’t see some tweets almost immediately then that’s a poor user experience. However content delivery for most sites is not as time critical; an e-commerce site’s catalogue will change relatively infrequently.

So my time with Backbone.js was not wasted; even software development is cyclical and subject to fashions. Every solution lies somewhere between the extremes; maybe it’s something akin to an all-purpose pair of ill-fitting slacks.




Alastair Aitken (124 Posts)

As a contract developer and manager I’ve worked in a wide range of enterprises in a variety of countries where I’ve encountered everything from great work, awful work, bizarre work, all the way down to quasi-legal work. If you think that you recognise your own organisation within my articles then you’re undoubtedly wrong, where you work isn’t that unique.

Leave A Response »