<div class="gmail_quote">On Mon, Jan 26, 2009 at 9:37 AM, John A. De Goes <span dir="ltr">&lt;<a href="mailto:john@n-brain.net">john@n-brain.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The best approach is to push as much functionality into the client as possible. The ideal server-side framework consists of nothing more than a permissions-based interface to persistence and network services. That&#39;s it. Everything else is done on the client side, in JavaScript.<br>

<br>
Web designers can pretty easily style dynamically generated HTML, if the semantics are good -- you just need to let them capture that HTML in any given part of the application.<br>
<br>
What this means is that effort is probably best directed at Yhc/JavaScript and similar projects, which compile Haskell to JavaScript for execution on the client. Sure, some server-side work needs to be done, but it&#39;s extremely minimal. Far more needs to be done on the client-side. There&#39;s not many people working on that and the infrastructure is in need of more creative input and development resources.<br>

</blockquote></div><br>That&#39;s great in theory, but then you end of with inaccessible web sites, those without Javascript are left out in the cold, and search engines won&#39;t index you. I think any framework should transparently make a site work the way you describe and as plain HTML.<br>