rich web client vs thin web client

I have one design decision to make.

In my web(ajax) application we need to decide where should we put user interface logic ?

Should It be completely loaded via javascript ( pure single page ) . and Only data comes and go.

or

Should server send some format (XML) which translated via javascript to dynamically create rich user interface. ( semi开发者_开发知识库-ajax ). so some data and ui comes and go.

Which option is better ? ( speed, ease of development, platform independence )

Thanks.

IMO, it depends mostly on what kind of application it is. Is it used more like a desktop application? Then single page might work well. Having an Ajax-client to a large extent has the same drawbacks as using frames but that isn't a big problem in desktop-style applications.

Your second option works better if it more like a traditional website with many different pages with dfferent content, Then you want to have separate URL's to that different content. But then making an Ajax application might not give you all that much in the first place. Having some bits of Ajax on the page might be useful, but loading all the data with Ajax might not add anything to your app, except making it slower.

I faced similar dilemma few months back. As Lennart (above) says it makes sense to go for pyjamas or similar library if your app is more desktopish. Further one of the biggest advantage of pyjamas provide is logically well separated backend and frontend code. IMO that is very important.

If your app is not like a desktop app (like ours was), then multipage offers more advantages, such as single change wont breaks entire app, easier to maintain etc. You might want to consider can have your app server serve json and other web server serves static content and js. Js would request json app server for data. That way we managed to keep out frontend and backend separate. Further we chose mootools as js lib over pyjamas. Ofcourse it is upto your taste and need of application. We did use python template server side templates but at compile time not at runtime like usual approach. This needed to change our thinking a little but the offered many advantages.

I end up telling you my story but I thought it's relevant and hope that helps.

The biggest influence is whether you are concerned about initial page load time. If you don't mind having all the UI there at page load, your app can be more responsive by just shuttling data instead of UI. If you want faster load and don't mind larger AJAX requests, sending some UI markup isn't bad. If you have the server power to pre-render UI with data and send the fully-ready marked-up data to the user, their browser will perform more quickly, and initial page-load should be fast.

Which course you choose should depend on the task at hand. Not all requests need be handled the same way.

Which option is better ? ( speed, ease of development, platform independence )

Platform independence, if you mean cross-browser compatibility, is a HUGE reason to use pyjamas because the python code includes a sane override infrastructure which handles everything for you. No more JS compatibility classes.

Anyway Pyjamas is all about loading the client app and then using json-rpc for the data only. That's because it's faster (once the app loaded up), easier to separate server and client, easier to maintain since all the UI code is in widgets in one place.

I've seen stuff like DokuWiki which use a php script to serve up javascript and my first thought was "WHY?" but it works pretty well I guess. It probably makes sense if you mostly have static pages with the occasional bit of JS for decoration.