[web-devel] richer client experiences

[Michael Snoyman]

On Tue, Jan 25, 2011 at 11:00 PM, Greg Weber <greg at gregweber.info> 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 at 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