It sounds like you have a very language-centric view of the world. In practice, deployment is everything. (Why do people write code in Objective C? Because iPhone.)
Having a solid implementation for your target platform is very good reason to pick a language.
> It sounds like you have a very language-centric view of the world.
> Having a solid implementation for your target platform is very good reason to pick a language.
I'm not sure where you got that out of my comment; it was exactly the opposite.
My point was that neither OCaml nor Haskell have particularly strong implementations in this area (to my knowledge). Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders").
And that still doesn't change the fact that a web app can be written in any language - the only part that needs to run in Javascript is the client-side. Depending on how you architect your app, this may not be much at all. (There are very few webapps that actually need much logic in Javascript - if you want to avoid JS[0] while writing complex webapps, it's actually very easy to do so in many cases.)
> Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders").
Facebook uses an OCaml js_of_ocaml-based frontend for a large chunk of their production code editing. Not a great video, but here's the CUFP 2013 talk on the topic: http://www.youtube.com/watch?v=gKWNjFagR9k
I looked at Haskell options - fay and haste are both good, but not complete (try compiling tagsoup). GHCJS works, but generates 5mb JavaScript files.
This is what I meant when I said "by virtue of support for existing libraries". js_of_ocaml translates compiled bytecode and can therefore make any pure OCaml library work in JavaScript without recompilation.
Okay, sounds like a misunderstanding about what "web app" means. Sorry about that!
I think of a web app as the client side alone, which can be quite a substantial amount of code with something like GMail or Google Maps. Of course on the server side, you can make a mostly-independent choice of language, RPC mechanisms aside. But for the client side, I'd choose a language based on how well it compiles to JavaScript and can use browser API's and JavaScript libraries.
I don't know whether OCaml is ahead of Haskell in this space. I've tinkered with Elm a little bit.
Having a solid implementation for your target platform is very good reason to pick a language.