Thick or thin clients for AJAX

2006-02-02 23:39:00

AJAX allows you to move a lot of the 'smarts' in your Web app from the backend out to the client. This raises some interesting questions -- e.g., how much of your app's logic should you offload to the browser? Brad Neuberg has an interesting Weblog post on this question of thick versus thin clients with AJAX.

With a thick client, the client-side code has all three of the model, view, and controller, and the server is simply a source of data, providing some kind of simple API for retrieving it -- like REST, XML-RPC, or JSON-RPC. It returns structured data like DSV, XML, or JSON which the client uses for generating UI markup on the fly. This is the approach we're going with for Scooby.

In a thin-client setup, the browser provides only the controller, and user actions trigger requests to the server, which actually generates all the markup. The client then just pulls it down and inserts in the UI (usually using a method like innerHTML). This is much less AJAXey, and pretty close to the way Web pages and Web applications have been working for a long time the only difference here is that the requests can be asynchronous, and the entire page doesn't have to be re-rendered at once.

The upside to thick-client approach is that it takes full advantage what is possible with AJAX-style development, and creates a really responsive, performant application.

Brad really nails it with his description of the potential downside of this approach:

The Thick Client approach moves most of the software engineering to the client; it's weaknesses are that it is a new environment for server-side programmers, many of whom don't respect JavaScript or the level of software engineering it can require to produce quality results. It is difficult to find DHTML programmers who know how to work within this environment.

The thin-client approach is much more comfortable for server-side programmers and traditional apps programmers. As Brad puts it, "It's [sic] strength is that it builds on familiar and available server-side skills, and can sometimes be used to leverage an existing system."

The main problem with doing everthing on the server of course is that each user action requires a round trip back and forth, and as your application gets more complicated, it begins to bog down. This approach doesn't scale well, and only works with the simplest UIs.

My suspicion is that with the influx of server-side devs and traditional apps programmers doing Web stuff, specifically AJAX-style development, that a lot of supposedly AJAXey applications are leaning heavily on the thin-client approach, which doesn't maximize the advantage of using AJAX in the first place. It often results in a really pokey-feeling application.

Having a lot of experience on the client-side, I of course am biased heavily toward offloading as much stuff to the browser as possible. I think that usually provides the optimal end-user experience, as you do as much as possible in real-time right there where the user is. But there are issues with rendering your markup client-side that are not mentioned in Brad's post, and I think are worth noting. I'll write about those in another post.


This is the blog for Matthew Eernisse. I currently work at Yammer as a developer, working mostly with JavaScript. All opinions expressed here are my own, not my employer's.


Previous posts

All previous posts ยป

This blog is a GeddyJS application.