I have to say, I don't really think Erlang is suitable for front-end stuff. Its string handling is just not good enough for the most common web tasks.
Also, this smells a lot like .Net's datatables etc., which go against modern front-end best practices.
While Erlang is not the first choice one would make for heavy string processing, in most web apps you are doing far less string processing than people assume. For an Erlang solution you just keep the "string" as an Erlang binary and pass it around in this raw form. With the addition of unicode to the list of types that are available for processing with the Erlang binary datatype in the recent R13 release this option is becoming more interesting.
The focus on Comet and an event-driven model remind me of HAppS. Is there something about this approach that's especially appealing in pure functional languages?
Maybe not in pure functional languages per se, but it meshes nicely with the actor model that underlies most of Erlang's computational abilities.
Interesting - I've long said that I think Erlang might be well suited to very ajax-intensive apps. It's not that great as a templateing language, but does ok when you're just passing json back and forth. I suppose the issue is sorting out what sort of 'model' component to use... Mnesia, CouchDB, or a more traditional db?