mikepk.com about current projects contact

Thin versus thick client? It's a non-argument.

January 30, 2006

I'm taking a quick detour from my usual "javascript-magic-ninja-foo" articles to post some thoughts on general architecture. I recently posted a comment on Brad Neuberg's blog "Coding In Paradise" in response to a post entitled "Should I Render My UI On The Server or the Client?".

It's interesting that the responses to that post seem to me to sound almost religious in nature. I agree with Brad in most ways, I really believe it's a non-argument. I think in this case, as is frequently the case with countervailing technologies, the imagined hard lines between the two will become blurred over time and the solutions will emerge as what's important (old enough to remember the arguments between CISC and RISC?).

Developers are notorious for wanting to stick with what they know, the "everything looks like a nail if I have a hammer" syndrome. Sometimes (especially early in a new technologies life) those developers are so artful with their particular tools that they can do some amazing stuff. They're able to use their "hammer" in all sorts of ways that even the hammer manufacturer never imagined, the great hacks. That doesn't necessarily mean that it was the correct tool for the job, or even the correct approach.

I think the architecture that keeps the display logic fully on the server side will begin to show weakness for all but the simplest UI's. In other cases, especially more complex UI's, the client is increasingly where you want at least some of your display logic to go. What is really needed are tools that increase the productivity of developers on the client side. Yajaf is one such framework, trying to make it easy to rapidly build complex GUI's that have really great performance.

One of the universal constants in the field of computing is, local is fast, remote is slow. Processors and caches, parallel computing paradigms, and networked distributed systems all exhibit this constant. While processing speeds, latency improvements, and bandwidth improvements have all increased at astonishing (even exponential) rates, each is increasing along a different curve. If we take the larger picture, and project out what the future holds, processor improvements far outpace bandwidth improvements. You can argue that javascript, with it's interpreted nature within a browser, is too inefficient. If the history of computing teaches us anything it's that inefficiencies rapidly become irrelevant as they are steamrolled by the inexorable improvements in raw processing capabilities.

If we just imagine the argument in terms of capabilities, by utilizing only server side UI logic, you are deriving most of your capabilities from the bandwidth and latency improvement curves. With this type of architecture you end up ignoring the most rapidly improving element in your system, the powerful end nodes, using them as nothing more than HTML rendering engines. Eventually, as rich internet applications become more complex, those applications that tap into all three technology improvement curves will be capable of a lot more than those that tap only into one or two of them.