To Bardur Arantsson and those with the vision of a richer client-side experience- I very much share that. The Yesod Widget model may be basic, but provides you with the concept of bundling the client-side aspects of html, css, and javascript together. Currently the server-side integration is for form elements that can be integrated with Persistent. We are certainly open to adding more advanced functionality. The advantage of this widget system is that it is at a level of abstraction that is still very approachable for web developers, and works well for its current use case (nicer form inputs). To me, the disadvantage of (extending) the current way of doing things is that it relies on javascript widgets (specifically jQuery-UI, although it is pluggable to use different frameworks) which hide everything away from you, so if there isn't a configuration option for what you want things get frustrating. I think the best solution may not be focusing on creating even greater abstractions on the server side, but instead to use the right ones on the client side. Cappacino had a vision of rich clients, and went to the effort of turning javascript into a (apple-based) desktop programming environment, but they simply adopted the REST model for communicating back to the server [1]. One could easily use Yesod, Rails, or any framework configured to be based on REST. What cappacion has accomplished is very neat, but as someone with experience in web devlopment and little in desktop development I don't need to learn how to program an apple desktop and deal with the leaky abstractions. There are a plethora of client-side tools (SproutCore, ExtJS, qooxdoo, much more) that can give you a richer client-side experience without tying one down to a specific server-side implementation while still feeling like web development. However, they are still generally very widget-based and heavy-weight, which is why I have been trying out backbone.js lately [2]. Backbone provides an MVc framework on the client side- the basic plumbing for creating a rich client, giving you control of your data in the way you are used to on the server side. You can choose to use javascript framework plugin or to program custom views. This direct client-heavy model works well because you can program it more directly instead of working through layers of abstraciton on the server side to generate a richer client. I would say the main down-side is duplicated logic and templates between the server and the client. I would like to start evolving techniques to be able to share server and client-side logic and templates, but in the mean-time I can be productive today without having to create new frameworks. I don't think the final solution requires throwing away all existing server-side web frameworks. One of the problems with client-heavy is programming in javascript, but much of this can be solved by using coffeescript [3]. Certainly there is still a problem with lack of type safety and difficulty of testing, but not one that can't be overcome and helped by integration with tools provided by the server-side framework. [1] cappuccino.org/ [2] documentcloud.github.com/backbone/ [3] jashkenas.github.com/coffee-script/