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

by mikepk on 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.

  • Brad GNUberg

    Interesting piece.

    You’re right that the boundaries I identified in my opinion piece will blur. I’m still waiting for someone to do something like the following:

    Take an XML UI description language, such as the one Backbase has. Instead of pushing that XML language to the client to be parsed at runtime, which is super slow (and makes Backbase very slow, by the way), precompile it on the server-side into JavaScript. This JavaScript contains the model and the controller, which used to be represented in XML (or perhaps was represented as Java objects, which are turned into JavaScript).

    Now, you can work with a familiar, consistent server-side model, but it gets compiled into a fully client-side system (perhaps your model objects, represented by Java, get converted into JavaScript for the client side, but also live on the server side behind your web service API, so you only have to take care of one model codebase).

    The one issue with this is debugging, since you are dealing with generated JavaScript, which can be fugly.

  • mikepk

    Brad, what kind of XML description would you be interested in? What would be the primitive UI structures? (i.e. fundamental widgets like panels and sliders?)

    I could make something like you describe, it might take a little work but since YAJAF is fully object oriented, pushing objects to the client would be perfectly natural. Maybe the intermediary ‘language’ could be json which might be easier to debug.

    I have a lot of debugging tools built into the library to help out with this kind of thing as well.

    I’m looking for some sample applications to promote this library/framework thing I’ve made. The intermediary XML->js language thing might be a nice feature to get server-side people interested.

Previous post:

Next post: