On Tue, Jan 25, 2011 at 11:00 PM, Greg Weber wrote:

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/ _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

I have to agree with Greg here: although I've never personally used GWT or its ilk, from everything I've read it works well about 95% of the time and then makes you want to gouge your eyes out with a rusty, anthrax-laden spoon. It could be that this is simply not true, and it could be this is a problem with the implementation, not the concept, but it's frankly one of the reasons Yesod has stuck to more traditional web framework theories. I only recently heard about backbone.js, and it looked intriguing. I'm going to have to do more research into it. Regarding coffee-script: I think having a Haskell equivalent would be an awesome tool. This could also be another great moment for the Haskell web community to work together. Michael

On 2011-01-25 22:00, Greg Weber wrote:

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).

[--snip--] I get this definite feeling that people are assuming that I'm somehow "afraid" of the client side... which isn't the case. I don't have a problem with programming client-side, and I'm actually quite comfortable programming JavaScript with, say, jQuery. (Douglas Crockford has a lot to do with that.). I just think that it's pointless if you can move to a better way of doing things. There are problems with this model, though: - Testing is horrendous. I'm well aware of things like Selenium, but I want to be able to guarantee that the JavaScript is correct *by construction*. The server-side component can generate correct JavaScript for each browser if there are differences. It is extremely rare that I see completely correct hand-coded JavaScript *in practise*. - No static typing. I want to work in a statically type checked environment all the way to the user. That includes checking that a server-side callback is actually receiving a correctly typed message from the client and such things. I want the framework to handle this correctness checking (and related security) *for me*. - Usually there's a LOT of boilerplate code that goes into the client<->server communication bits, packaging the client UI state into JSON, posting that and unpacking the results into some client UI, etc. IMO, Wicket and Vaadin solve this reasonably elegantly (maybe not at the implementation level, but I'm also trying to address that). However, it may just be that I haven't seen "the right way" to do this. - Cross-component consistency in Look & Feel may be easier to achieve for your average application developer. On 2011-01-25 22:00, Greg Weber wrote:

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.

The things is: You won't have to. The goal is to be able to trivially be able to compose widgets/components to get larger/better widgets/components. One just needs to bootstrap just enough of the compontents which can be used as building blocks. This is easy in Wicket. Cheers,