John A. De Goes wrote:
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's it. Everything else is done on the client side, in JavaScript.
+1 This is the conclusion I have come to in building collaborative Web applications. I agree that there seems to be a gap here in the Haskell Web frameworks people are building.
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.
I do not believe compiling Haskell to ECMAScript/JavaScript is a productive avenue. There is too much pain in trying to abstract away the JavaScript model only to write everything in Haskell and end up with worse performance as a reward. There is very little wrong with ECMAScript if people would only learn it properly and play to its strengths instead of trying to turn it into things it is not. Treating ECMAScript as a compiler target language will be a win eventually, I expect, but not by compiling from Haskell. Haskell could certainly play a role, e.g. as an implementation language for ES-to-ES or DSL-to-ES compiler writers. Michael Snoyman wrote:
That's great in theory, but then you end of with inaccessible web sites,
This doesn't have to be true. You can do quite well today if you are careful, and ARIA will resolve the remaining issues.
those without Javascript are left out in the cold,
Yes. JavaScript is a requirement for the full functionality of the modern Web.
and search engines won't index you.
This also isn't true if it's done right. It's almost always done wrong, but that's just ignorance and incompetence, not any inherent limitations of the technology. Follow correct principles of Web architecture and you can do fine with search engines, even if you rely on JavaScript to provide a UI. -- Michaeljohn Clement