Friday, January 27th, 2006

Brad Neuberg: render UI On The Server or the Client?

Category: Dojo, Presentation, Prototype, Usability

Brad Neuberg has a post worth reading on where to render the UI for ajax apps over on his blog. He talks about two general approaches you can take:

  1. Thick Client – basically the server just gives you answers to RESTful web service calls, and your client side code has its own mini-MVC approach so it can handle displaying objects, manipulating them, etc. Dojo facilitates this type of approach.
  2. Thin Client – just capture events and call the controller on the server, and the server returns chunks of prerendered html or javascript for display. This is more the Ruby on Rails/Prototype approach.

He goes on to give examples of both approaches and talks about the pros and cons of each. The thin client approach is more comfortable for server side developers, but can run into performance issues for complex UI’s, as you have to hit the server for every user event. The thick client approach requires more knowledge in client side technology, but can pay off in performance and responsiveness. There was also a discussion about this recently on the dojo-interest mailing list for further exploration.

Posted by Rob Sanheim at 2:27 pm
16 Comments

+++--
3.9 rating from 26 votes

16 Comments »

Comments feed TrackBack URI

I wanted to comment on their site, but they have registration required.

The problem with the thick client approach is: first you have to generate the initial layout on the server, presumably from a template. Then, when the user interacts with the page, you want to change parts of the layout on the client.
For this, you need access to a template for the component you want to change, but this time on the javascript level. So you have two different template systems, which will run you into redundant or fragmented layout work.

One solution would be a template format that can be used by the server scripting system and the javascript system.
Or maybe a server system that can create javascript templates from its existing templates. Anyway it’s somewhat messy.

Comment by wooyay — January 27, 2006

The thick client, like Bindows framework, which is a good example and benchmark since it’s pure genious, is much slower than anything serversided I have come across.
It can take several seconds to respond if it’s a lot of data, which most useful apps require, and which also is the whole point of the article to begin with.
Newsalloy is much faster, and ironically enough more so, when it’s a lot of data, which kinda goes against the argument.
I simply clocked it – not to many has done that.
– It’s mostly unchallanged assumptions being made in this article.

Comment by Mikael Bergkvist — January 27, 2006

mikael: I think bindow is slow because firefox is really sluggish when moving or replacing large divs. I would have liked to compare this on another browser, but the demo on the bindows.net start page does not appear when I open it in konqueror. Shame on you bindows.net!

Comment by wooyay — January 27, 2006

Wooyay, in the thick client approach the server is not rendering any templates; the server becomes a thin web-service facade with no view or controller logic. Instead, templates and so on are on the client-side. The thick client approach means you don’t have to maintain two sets of view logic.

Mikael, not all AJAX/DHTML frameworks are created equal. In the opinion piece I mention that you have to do excellent engineering with the thick client approach to get good results, but you can potentially have a much better solution. I actually find News Alloy to be sluggish, because _everything_ is on the server (they use the thin client approach). I can’t speak for Bindows, because I don’t know much about it, but I do know from Dojo that if you architect your app correctly you can have a superior solution.

No silver bullets; if you have a simple app with small bits of HTML and very simple AJAX/DHTML, just use a thin client; if you are building a web based email system, a next-generation aggregator, or something else snazzy, and you want it to actually be the best in the world, get some awesome engineers and do the thick client approach.

I should have also mentioned to _not_ overengineer the thick client, or force thick clients to be too desktop like, which can slow them down, but thats a different opinion piece.

Dion and Ben, thanks for pointing to the piece and adding your comments.

Comment by Brad Neuberg — January 27, 2006

Brad: no problem, it’s Rob here btw – Dion and Ben are traisping around Europe. :)

Comment by Rob — January 27, 2006

Hi Rob! What are they doing in Europe? What kinds of AJAX/DHTML things are you hacking on these days?

Comment by Brad Neuberg — January 27, 2006

Make the balance of Thick and Thin of Server and Browser will be a job!

I am wondering at the idea that once the whole thing, including client browser side and server side, can be programmed in one language such as Java, will the balancing will be an easy job.

Currently, I am working on Java2Script Pacemaker at sourceforge.net, which provide toolkit to programm the client browser side in almost Java. Sure, part of the Java codes can be re-used in the server side. Maybe balancing between server and client can be easily done once the whole things are integrated together.

Comment by josson smith — January 27, 2006

I’d like to point out that Dojo can support thin-client server-centric apps too. You can return big chunks of HTML and plug it into the innerHTML of a div with Dojo very easily.

Comment by Jason Carreira — January 28, 2006

I think there are some really big problems from an architectural standpoint when building AJAX apps, which comes from the following paradox:

Architecturally the cleanest way to develop AJAX apps is to have a Fat client on one side and a web service on the other. This allows the web service to be used by other interfaces. However its no fun generating html on the client side; it just feels clunky, server side technologies are simply better at doing it.

So I’d like to code web services then a fat client, but its just a nightmare to do all that layout and design HTML from within Javascript. So inevitably more and more code is contained within the server side, and you have what feels like a kludged architecture with the Model on the server side, and the view and the controller equally spread over the client and the server. Yuk.

Possible solutions: Somehow javascript gets better at handling HTML, (unlikely) Someone builds a nice UI/system to save us handcoding Javascript generated HTML (Any offers?)

Now I suppose that XML/XSLT could probably help things along, but I dont know a lot about that, I get the impression though that its not quite ready. But if anyone cares to illuminate me in that regard, go right ahead!

Comment by Paul o — January 28, 2006

konqueror is irrelevant

Comment by Mario — January 29, 2006

Prado is an example of a templating system that will allow for both client and serverside thicknesses

Comment by Mario — January 29, 2006

Mario: Maybe konqueror is not widely used, but it has the same codebase as safari. And as many web dev geeks are mac fetishists, this is important.

Brad: Dojo loads all templates by javascript after the page loaded. This makes it pretty slow to get started. I think a good solution page-loading wise is this: load the initial page as HTML generated from templates by the server side. After loading, let javascript apply templates to newly added or changed elements. This should be faster than styling by javascript, and less HTML has to be loaded through ajax.
By the way, as far as I know a TCP packet has 2 kb. I think it does not make a big difference if you update a page element by loading html or just loading a js function call. 2 kb of html is a lot of content if you use stylesheets to do your styling

Comment by wooyay — January 29, 2006

I figure I should mention Freja ( http://www.csscripting.com/freja ).
It is a thick-client javascript framework. It follows the MVC pattern and under the hood it’s a client-side XML/XSLT engine.

From my experience, transforming a 70kb XML using a XSL stylesheet and inserting the resulting HTML into the DOM is still faster than doing back & forths with the server.

Comment by cedsav — January 30, 2006

Great thread. I have craeted a couple of examples using assorted dojo widgets – and my observation of this is that initegrating with an existing app server would be alot easier if the dojo widgets had a way to interoperate with server generated html – it does not work so well at least with certain controls. Dont get me wrong, we definitely want to move to a dojo client paradigm, but it would sure be easier if there were more server side support. Makes me wonder if there is not a ‘yet to be created widget’ that could help in transition.

Comment by epb — February 8, 2006

Why try to create a new pattern or new semantics? The author discusses MVC, but then conflates the intents and purposes of that pattern via a “thick” or “thin” paradigm. Having the appropriate levels of abstraction between Model, View and Controller is important. If you are moving to a “thin” client, then you will likely not be practicing MVC.

-The Model, Controller and the View would each get polluted with one another.
– The organizational strucutres in roles and responsibilities get lost since the abstraction that is core to MVC become “fuzzy”.
– As others have pointed out, the abstration between the M from the V and C is some facade such as web services or similiar.
– The more you push VC closer to the Model, the great the likelyhood that you will find that any change becomes a “backendâ€? change managed by a group of people who have no interest in changing anything in the “systemâ€?.

I suppose if you are a lone developer or in a small shop you have the end to end view, do whatever you want and give it whatever label you want. At the end of the day, MVC or not, it matters little if you are responsible for all aspects. It might not be a best practice to pollute your stated MVC objectives, but you can manage that right? When you are working at a medium or larger scale, having the appropriate design patterns in place provides critical firewalls for disparate groups of engineers scattered across the globe.

In a medium or larger scale setting, having the appropriate design patterns in place provides critical firewalls for disparite groups of engineers scattered across the globe. I could not imagine pushing the VC and controller back to IBM Global Service, WIPRO or any other host of vendors who manage that side.

Comment by Talo — February 12, 2006

One solution would be a template format that can be used by the server scripting system and the javascript system.

Such a format already exists – it’s called XSLT.

Comment by troels — February 28, 2006

Leave a comment

You must be logged in to post a comment.