[web-devel] richer client experiences
greg at gregweber.info
Tue Jan 25 22:00:18 CET 2011
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
Currently the server-side integration is for form elements that can be
integrated with Persistent. We are certainly open to adding more advanced
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
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
simply adopted the REST model for communicating back to the server . One
could easily use Yesod, Rails, or any framework configured to be based on
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 .
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
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.
of this can be solved by using coffeescript . 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel